> 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:
RCS file: /usr/local/cvsroot/ethereal/proto.c,v
Working file: proto.c
...
revision 1.78
date: 2000/08/22 06:38:18; author: gram; state: Exp; lines: +10 -8
Change FT_NSTRING_UINT8 to FT_UINT_STRING. The length parameter passed
to proto_tree_add_item() will indicate if the length of the string is
indicated by an UINT8, UINT16, UINT24, or UINT32.
Change NCP dissector-maker to produce FT_UINT_STRING.
Fix off-by-one in dissection of some NCP reply packets.
> FT_STRING is useful for pulling out a fixed-length string from a packet,
...if you use "proto_tree_add_item()" rather than
"proto_tree_set_string()" ("proto_tree_set_string()" uses "g_strdup()",
so the string you hand it has to be NUL-terminated).
Note also that "fixed-length" here doesn't appear to mean it can only be
used if all instances of a given string have the exact same length; it
appears to use the length argument to "proto_tree_add_item()", so it
could be used for variable-length counted strings (which can't always be
handled by FT_UINT_STRING; see below).
> or adding a string from C code (that is, not have proto_tree_add_item()
> pull it out for you).
In that case, the string is NUL-terminated, nto counted, as
"proto_tree_set_string()", as per the above, uses "g_strdup()".
> FT_UINT8_STRING is used only in proto_tree_add_item(). That routine pulls the
> uint8 from the tvbuff and uses it as the string length, and pulls that
> many more bytes from the tvbuff to represent the string.
As per the above, it's now FT_UINT_STRING, and the length and
little_endian arguments to "proto_tree_add_item()" specify how big, and
what byte order, the count immediately preceding the string data is.
> When FT_STRINGZ is done, proto_tree_add_item() will search for a
> terminating NUL in the tvbuff, up to a maximum length that is passed
> in by you as the length parameter, and use the
> string if it finds the terminating NUL.
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()".
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*.
