Wireshark · Wireshark-dev: Re: [Wireshark-dev] [Wireshark-bugs] [Bug 3138] New: Buildbot crash output: fuzz-2008-12-18-2313.pca

[Guy Harris <guy@xxxxxxxxxxxx>]

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.