Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] how to handle dissecting length encoded strings

From: Chris Maynard <chris.maynard@xxxxxxxxx>
Date: Mon, 14 Mar 2011 20:18:48 +0000 (UTC)
Jakub Zawadzki <darkjames@...> writes:

> hf of type FT_UINT_STRING wouldn't work for you?
> 
> FT_UINT_STRING      
> 	A counted string of characters, consisting
> 	of a count (represented as an integral value,
> 	of width given in the proto_tree_add_item()
> 	call) followed immediately by that number of
> 	characters
> 

Thanks for pointing that out Jakub.  I think that's the best solution.  I got
caught up looking through the tvb_get_nstringz functions and didn't pay
attention to what the dissect_octet_string() function was actually trying to do.

But speaking of tvb_get_nstringz ... why does _tvb_get_nstringz only search up
to "limit - 1" bytes for the NULL-terminator?  If the NULL-terminator is in the
limit_th byte, the function will incorrectly return (-1) and the returned string
in "buffer" won't be properly NULL-terminated ... unless length remaining is
less than bufsize.

And speaking of that, why does it NULL-terminate the string if the number of
bytes left in the tvb, len, is less than bufsize?  If we're doing that, it would
seem that for consistency a NULL-terminator should be written even when len >=
bufsize.  And if that is done, then we wouldn't really need tvb_get_nstringz0,
which seems to suffer from a potential buffer overflow problem anyway, where, in
the case when len < bufsize from within _tvb_get_nstringz, tvb_get_nstringz0
will still write a NULL-terminator to buffer[bufsize - 1] whenever
_tvb_get_nstringz returns (-1), irregardless of whether that was because len <
bufsize or not.