On Fri, Aug 25, 2000 at 11:32:08AM -0700, Guy Harris wrote:
> > Re: strings, we use char* inside the code. We have FT_STRING, and
> > FT_UINT8_STRING.
>
> No, we have FT_STRING and FT_UINT_STRING; somebody changed
> FT_UINT8_STRING to FT_UINT_STRING a few days ago:
That somebody was me. How soon I forget my own nomenclature. :)
> There should also perhaps be a "proto_tree_add_stringz()", which would
> act as "proto_tree_add_string()" acts now, and perhaps we should nuke
> "proto_tree_add_string()" (it seems a bit counter-intuitive that
> FT_STRING takes a counted string in "proto_tree_add_item()" and a
> NUL-terminated string in "proto_tree_add_string()") in favor of
> "proto_tree_add_stringz()".
Agreed.
> If there are any cases where "proto_tree_add_string()" is currently used
> to add a counted string *and* is being handed a pointer into the packet
> buffer, they need to be fixed, given that, as per the above,
> "proto_tree_add_string()" expects the string to be NUL-terminated.
>
> What does FT_STRINGZ do if no NUL is found by the time the maximum
> length is reached? I suspect it should act as if there were a NUL right
> after the maximum length, i.e. copy the maximum length of bytes worth of
> string data into the buffer allocated for the protocol tree item, and
> then stick a NUL after it in that buffer, as some protocols have string
> fields that take up a fixed amount of space in the packet, but that are
> NUL-*padded* rather than NUL-*terminated*.
Good question. Last night I couldn't decide between the above behavior
and reporting (in the proto_tree) an error. But because of the
NUL-padded situations, I agree with the above proposal.
--gilbert
