Re: how to handle dissecting length encoded strings

[Chris Maynard <chris.maynard () gtech com>]

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.

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe