Wireshark-dev: Re: [Wireshark-dev] how to handle dissecting length encoded strings
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.
