On Thu, Apr 27, 2000 at 02:28:24AM -0500, Guy Harris wrote:
>
>
> 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.
That sounds good.
> 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.
Sure. That sounds like a big performance win by cutting down on the amount of
copying done.
--gilbert
