Skip to content
Snippets Groups Projects

Export tvb_format_stringzpad() functions

Closed John Thacker requested to merge johnthacker/wireshark:export_format_stringzpad into master
1 unresolved thread

Make tvb_format_stringzpad() public, so it can be called from plugins.

Merge request reports

Loading
Loading

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
  • John Thacker added 3 commits

    added 3 commits

    Compare with previous version

  • John Thacker resolved all threads

    resolved all threads

    • So where would this be used, rather than, for example, doing proto_tree_add_item_ret_display_string() to add the item to the protocol tree and using the resulting "display string" as the formatted string?

    • 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 of tvb_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 of tvb_get_stringzpad() plus format_text_string() is equivalent, with tvb_format_stringzpad() really just being those two together with the common defaults of wmem_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 to proto_tree_add_string_format[_value](), possibly also passing it to col_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 calling proto_item_[set|append|prepend]_text() on the subtree later, though that feels less natural to me.)

    • Please register or sign in to reply
  • 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 calling proto_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.

  • closed

  • Please register or sign in to reply
    Loading