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?
