Comment # 22
on bug 9323
from Jakub Zawadzki
(In reply to comment #21)
> (In reply to comment #20)
> > Still I'd rather see caller responsible for NUL terminating string.
> > IMHO dissector should either use proto_tree_add_item() [and don't care about
> > encoding, NUL terminating] or use proto_tree_add_[unicode]_string() with
> > tvb_get_string_enc().
>
> There are cases where the caller can't assume NUL termination without doing
> a copy (with strndup or etc), but then proto_tree_add_string will just take
> its own copy. So I guess proto_tree_add_string_count is just an optimization
> to avoid the extra copy.
Sure, and user would not need to NUL terminate it if given field is worthy
fetching (like: tree =! NULL), still this is penatly for not using
proto_tree_add_item.
So do we really need proto_tree_add_string_count()? or can we convert most of
the calls to proto_tree_add_item() and some with proto_tree_add_string +
tvb_get_string_enc.
> The HTTP dissector is already using tvb_get_ptr for
> performance reasons, so adding an extra copy kind of defeats the purpose of
> that.
I'm not quite sure about what code we're exactly talking about, in most cases I
think proto_tree_add_item() should be same speed compared to
proto_tree_add_string(.., tvb_get_ptr())
(both proto_tree_add_item() and tvb_get_ptr() checks if passed offset is within
bounds, later proto_tree_* checks if hf-field referenced -> return if not).
You are receiving this mail because:
- You are watching all bug changes.