On Oct 4, 2011, at 10:53 AM, Bill Meier wrote:
> For the next step is it simply a case of replacing the remaining TRUE/FALSE encoding parameter by ENC_LITTLE_ENDIAN/ENC_BIG_ENDIAN ?
Except for FT_STRING, FT_STRINGZ, and FT_UINT_STRING, for which an encoding should also be supplied. Presumably all the uses of proto_tree_add_item() and the like for FT_ABSOLUTE_TIME values already have the encoding specified and already use ENC_LITTLE_ENDIAN/ENC_BIG_ENDIAN.
> One thing I don't quite understand: In a number of the dissectors why do proto_tree_add_item() encoding parameters for hf items with type FT_STRING have ENC_ASCII *and* ENC_LITTLE_ENDIAN|ENC_BIG_ENDIAN ?
> Shouldn't this be ENC_ASCII | ENC_NA in this case ?
The endianness is irrelevant for ENC_UTF_8, ENC_ASCII, and ENC_EBCDIC.
In the future, there will be ENC_UTF_16 and possibly ENC_UCS_2, for which the endianness will be relevant.
Should we always specify an endianness for strings, or only for those character encodings where it's relevant?
