Wireshark · Ethereal-dev: Re: [ethereal-dev] cvs commit: ethereal packet-aarp.c

[Guy Harris <gharris@xxxxxxxxxxxx>]

> 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.

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.

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.)