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? ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <[email protected]> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
