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
