Re: Replace TRUE/FALSE with proper ENC_* in proto_tree_add_item() using a script.

[Stephen Fisher <steve () stephen-fisher com>]

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-request () wireshark org?subject=unsubscribe