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.
