> > 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 comment for ENC_NA: /* * For protocols (FT_PROTOCOL), aggregate items with subtrees (FT_NONE), * opaque byte-array fields (FT_BYTES), and other fields where there * is no choice of encoding (either because it's "just a bucket * of bytes" or because the encoding is completely fixed), we * have ENC_NA (for "Not Applicable"). */ #define ENC_NA 0x00000000 Based on your example, it seems you might be incorrectly using "ENC_NA" to mean "endianness not applicable". In any case, I don't think it ever makes sense to specify "ENC_NA" with an encoding (e.g., ENC_ASCII | ENC_NA = "Use ASCII encoding" *and* "Encoding doesn't apply here"). I would only expect to see ENC_NA on its own, but I could be wrong.
___________________________________________________________________________ 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
