On Dec 19, 2008, at 2:46 AM, Martin Mathieson wrote:
> Looking at Gerald's change 27053, there were lots of functions that
> wanted to do the same thing as I wanted, but they had to call
> tvb_get_ptr() just to get the data the match the selected range of
> bytes.
The ones I see where it's doing that (rather than, for example,
calling tvb_get_ptr() to get the data and then formatting the data in
its own fashion, so it has to call tvb_get_ptr() in any case) are
either:
1) adding raw data for an item where something is wrong, and it's not
displaying the raw data;
2) adding raw data for an item where something isn't wrong, but it's
still not displaying the raw data;
3) adding raw data for an item with structure underneath it, and
possibly putting in fields under that for the structure.
Assuming that adding the data as an FT_BYTES field is useful for 1)
and 2), the routines I'd go for would be something such as
proto_tree_add_raw_data(tree, hfindex, tvb, start, length);
proto_tree_add_raw_data_format_value(tree, hfindex, tvb, start,
length, format, ...);
where the first of those would add an entry that displayed as
{name}: N byte{s}
and the second would add an entry that displayed as
{name}: {result of formatting}
For 3), assuming it's even worthwhile having the data as an FT_BYTES
field is useful, one could argue that the right thing to do there is
to add the bytes with just the field name, and add subfields under it,
appending to the higher-level item information about the subfields
that matter. That way, if, for example, you have only part of the
item in the packet, you'd at least get those parts of the item
dissected.
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <[email protected]>
Archives: http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:[email protected]?subject=unsubscribe
