Export tvb_format_stringzpad() functions
Make tvb_format_stringzpad() public, so it can be called from plugins.
Merge request reports
Activity
- Resolved by Pascal Quantin
added 3 commits
-
23073a52...baebbbce - 2 commits from branch
wireshark:master
- bb24f6ea - Export tvb_format_stringzpad() functions
-
23073a52...baebbbce - 2 commits from branch
Well, one reason is that my understanding is that eventually,
proto_tree_add_item_ret_display_string()
should, for STRINGZPAD, actually include a representation of the padding bytes ('\000' or '\x0' or similar), and the description oftvb_format_stringzpad()
explicitly says it does not show the padding bytes. I think currently there's a lot of places where null padded strings get treated as C-strings and the padding gets silently removed when things get passed through the API, so some other approaches work that might not later. I suppose generally the composition oftvb_get_stringzpad()
plusformat_text_string()
is equivalent, withtvb_format_stringzpad()
really just being those two together with the common defaults ofwmem_packet_scope()
and UTF-8. If so, then I suppose there's no reason to add it other than to save some text in the common case.However, generally the use is in the cases where one wanted to format the string when displaying in the item, so
proto_tree_add_item_ret[_display]_string()
wouldn't work.In that case, would get the string with
tvb_format_stringzpad()
and then pass it toproto_tree_add_string_format[_value]()
, possibly also passing it tocol_append_fstr()
or similar.Also for cases of adding a subtree with
proto_tree_add_subtree
and wanting to put the name of the string in the subtree text field but add the item with the stringzpad to that subtree (I guess this can be done by creating the subtree first, calling the other item and returning the string, and then callingproto_item_[set|append|prepend]_text()
on the subtree later, though that feels less natural to me.)
Well, one reason is that my understanding is that eventually,
proto_tree_add_item_ret_display_string()
should, for STRINGZPAD, actually include a representation of the padding bytes ('\000' or '\x0' or similar),No. It should - and does - show the value of the string, which does not include the padding bytes, just as the value of a null-truncated string does not include the null character or the bytes after it.
For FT_STRING and FT_UINT_STRING, it shouldn't stop before a null character; for FT_STRINGZ, FT_STRINGZPAD, and FT_STRINGZTRUNC, it should stop before the null character.
If there is any place where any tvb_get_ routine is called and the result passed to a proto_tree_add_{type} routine, and that couldn't be done with proto_tree_add_item_ret_ routine, that's a sign that the API is inadequate.
However, generally the use is in the cases where one wanted to format the string when displaying in the item, so
proto_tree_add_item_ret[_display]_string()
wouldn't work.It should work with the display_string version - that's the whole point of the display string, it's supposed to be something you'd show to the user in the packet summary or details pane.
Also for cases of adding a subtree with
proto_tree_add_subtree
and wanting to put the name of the string in the subtree text field but add the item with the stringzpad to that subtree (I guess this can be done by creating the subtree first, calling the other item and returning the string, and then callingproto_item_[set|append|prepend]_text()
on the subtree later, though that feels less natural to me.)I'd call the latter a "best practice", as:
- if the packet is cut short before you get to a field value that's put into the summary line for the subtree, the stuff that's there before the (end of the PDU, end of the captured data, ...) gets dissected, and the dissection only stops when you hit the end;
- you only fetch fields once, and don't have to get the offset right (if, for example, you're stepping the offset forward as you proceed through the packet, you don't have to get the offsets right when you "prefetch" the values for use in the summary line for the subtree.
I've been converting to that practice over time.