Guy Harris wrote:
>
> > Ok, if so, we will have to add many FT_XXX types (e.g. FT_LITTLE_UINTX,
> > FT_BIG_UINTX, FT_NON_C_STRING etc.) and carefully choose the routine
> > arguments...
>
> The endianness could perhaps be separate from the type. In most cases,
> the endianness of a given field is fixed, and could be in another field
> of the "header_field_info" structure, and not have to be passed as an
> argument.
Yep. But in a general case, it is preferable to have this information as
a proto_tree_add_... routine parameter.
>
> The exceptions would be in protocols such as DCE RPC (where, if I
> remember correctly, multi-byte numeric values in packets are supposed to
> be sent in the sender's byte order, and fixed by the recipient) and X11
> (I think numeric values are supposed to be sent in either the sender's
> or recipient's order; I forget which). For those, you might have
> versions of the "proto_tree_add...()" routines that take an endianness
> value.
Yep. In some packets (GIOP for instance), the endianness is specified
in the packet itself...
> For strings, it would probably be a good idea to have different types,
> e.g.:
>
> FT_STRING_ASCII (perhaps with additional types, or other ways of
> dealing with "extended ASCII" character sets such as the ISO
> 8859 character sets, other EUC character sets, PC character sets
> used in SMB, UTF-8-encoded Unicode, etc.)
>
> FT_STRING_ASCIZ (like FT_STRING_ASCII, only '\0'-terminated)
>
> FT_STRING_UNICODE (for Unicode with 2-octet characters, as used
> in, for example, SMB - this may also require a byte order if the
> string doesn't begin with the "byte order marker" character that
> I remember Unicode having)
>
> and so on, so that the code that displays or prints protocol trees knows
> what to do with the string, and so that code to do string comparisons in
> display filters knows what to do with the string (Do we support string
> comparisons in display filters? If not, we will probably want to,
> eventually.)
Yes.
And maybe the delimiter in a proto_tree_add parameter (or in the structure)
so that we can specify for instance '\n' or "\r\n" or other non standard
delimiters.
Laurent.
--
Laurent DENIEL | E-mail: deniel@xxxxxxxxxxx
Paris, FRANCE | laurent.deniel@xxxxxxxxxxxxxxxxxxxxxxxxxxxx
| WWW : http://www.worldnet.fr/~deniel
All above opinions are personal, unless stated otherwise.
