On Fri, Jul 14, 2000 at 09:40:43AM -0500, Gilbert Ramirez wrote:
> Except, by "FT_NSTRING", I meant a string that has an initial byte that represents
> the length. But I believe Guy is working on a solution. So, we'll have:
>
> A string class that correlates to a C string... NUL-terminated.
> A string class with a predetermined length (for your dissector)
> A string class with a prefixed length byte (I'm sure some dissector needs it).
There'd have to be more than just that:
'\0'-terminated strings;
strings with an absolute fixed length (in the sense that the
protocol says "this field is N bytes long, and every single byte
is part of the string) - I infer that's what Neil meant by
"predetermined length";
possibly-'\0'-terminated strings with a maximum length (i.e., if
the maximum length is N, the field is N-bytes long, and if the
string is shorter than N bytes long, it's terminated (possibly
padded) with '\0';
strings with a prefixed 8-bit length value;
strings with a prefixed 16-bit length value;
strings with a prefixed 32-bit length value;
strings with a length that's none of the above, e.g. an ASN.1
string;
possibly others.
What I've been looking at are changes to
1) add a new FT_STRINGZ type, for '\0'-terminated strings ("Z"
for "zero-terminated", as per "ASCIZ");
2) use FT_STRING for counted strings;
3) have the routines to add FT_STRING values take, as arguments,
both a string pointer and a string length (in addition to the
item length value).
This leaves it up to the caller of "proto_tree_add_string" routines to
specify the length of the string.
For strings with a length value as part of the data in the packet, the
caller could specify offset/length values that include both the length
value and the string (if the length is contiguous with the string, or if
the intervening data could be thought of as part of the string as well),
or it could treat the length value and the string data as separate
items.
