I just checked in an ugly implentation of FT_NSTRING_UINT8,
a string that is prefixed by a single byte indicating the length of
the string. It's available only through proto_tree_add_item().
That is, there's no proto_tree_add_nstring_uint8() function.
Don't worry, I'm planning on changing how the it works. I checked it
in mainly because of a fix in proto.c that needed to be in. Soon
(within the next few days) I'll check in my NCP re-write, which uses
FT_NSTRING_UINT8. Once that's in place, I'll look at changing how the
strings work.
I am starting to think that there should be only a single string type,
FT_STRING. Through options passed to proto_tree_add_item(), we
can decide if the string is fixed-length, variable-length indicated
by an integer (1,2,3 or 4 bytes), or variable-length indicated by a NUL
character at the end, etc.
This is similar to how we decide endianness for integers. We don't
have separate FT_UINT16_BE and FT_UINT16_LE types --- the endianness
is decided at "run-time". This was done to support those protocols that
can flip-flop endianness. NCP uses strings in the same fashion. The same
string field can appear as an FT_NSTRING_UINT8 in a request, and then as a
NUL-terminated string in the reply. Why Novell decided to do this, I don't
know, but it appears that "type of string" is something better decided at
run-time rather than at registration time, much like integer endianness.
This would also be a good time to collapse FT_UINT* into FT_UINT and
FT_INT* into FT_INT... as Guy has noted in his comments in the source
code, the integer type can be determined by the number of bytes, which
is always passed to proto_tree_add_*()
--gilbert
