> ... I'd like to use FT_STRING for X11 strings. However, FT_STRING
> are null terminated, while X11 strings are not (the length is stored
> elsewhere in the packet). So do you think that it's worth a new type
> (FT_ARRAY or whatever), or may be a new representation for FT_STRING,
> or do you think that the problem is too specific to justify a change
> in proto.c ?
It's definitely not too specific - some mail I'd sent out earlier (sent
out when I was working on a LAT dissector, which is partially done; my
main patent concern on that one, BTW, was with the LAT daemon, not a
dissector):
Date: Thu, 27 Apr 2000 00:26:41 -0700
From: Guy Harris <gharris@xxxxxxxxxxxx>
To: ethereal-dev@xxxxxxxx
Subject: [ethereal-dev] Counted strings
Currently, FT_STRING values are null-terminated.
However, that's a bit of a pain if the string is counted and not
necessarily null-terminated in the packet - you have to copy the string
to a buffer and null-terminate the buffer.
If you add an item to the protocol tree, you have to specify a length -
but the length you specify isn't necessarily the length of the string
data, as
the item may include the length as well as the string data (if
the length isn't put into the tree as a separate item);
there might be padding in the string.
It might be convenient to have calls that add string items to the tree
take the length of the actual string data, as well as the length of the
item as a whole, and to make "value.string" be a structure containing a
string length and a pointer to the string data.
This might interact with the hack I've experimented with, which adds a
routine that, when adding an item to the tree, extracted the item from
the packet data for you. That routine would need to know whether the
string is null-terminated or counted, and would need to know the string
length if it's counted.
which I'd consider "a new representation for FT_STRING".
