Wireshark-dev: Re: [Wireshark-dev] Replace TRUE/FALSE with proper ENC_* in proto_tree_add_item(
Date Index · Thread Index · Other Months · All Mailing Lists
Date Prev · Date Next · Thread Prev · Thread Next
From: Anders Broman <a.broman@xxxxxxxxxxxx>
Date: Wed, 19 Oct 2011 19:52:48 +0200
Stephen Fisher skrev 2011-10-19 19:27:

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?
My preference is the opposite use ENC_BIG_ENDIAN as that is the "natural" encoding for the 
protocol  and ENC_BIG_ENDIAN is less confusing in my opinion.
Anders

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list<wireshark-dev@xxxxxxxxxxxxx>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
              mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe