On Tue, Oct 04, 2011 at 03:07:43PM -0400, Tony Trinh wrote: > 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.
I thought this was discussed already with regard to single byte protocol items, but if so, I can't find it now... I was taking a look at packet-vnc since I'm very familiar with the protocol and dissector and saw that ENC_ASCII was the right choice here. Then I came across ENC_BIG_ENDIAN for a single byte value (hf_vnc_num_security_types) which would have had FALSE before. Clearly, even the FALSE before didn't mean that it was big endian since it is a single byte. Presumably, I used FALSE because that is the right choice for multi-byte values in most network protocols. Should we use ENC_NA here too to prevent confusion? ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
