Re: Static analysis and FT_STRING encodings

[Guy Harris <guy () alum mit edu>]

On Apr 12, 2012, at 10:47 AM, Evan Huus wrote:

> 2. Most dissectors add FT_STRINGs with an encoding value of 'ENC_ANSII | ENC_NA'. Based on the comments in 
> epan/proto.h this doesn't make sense (they should be 'ENC_ASCII' only?),

Which comments?

We currently have no ENC_UTF_16, but, when we do, it would have to be ORed either with ENC_BIG_ENDIAN or 
ENC_LITTLE_ENDIAN, so, at least for some character encodings, a byte-order specification would make sense.

ASCII has no byte-order issues, and the convention is that ENC_NA is used to explicitly indicate that the byte order is 
not applicable.

The comment for ENC_NA should probably be updated to reflect that.

> and they cause CppCheck to complain because both ENC_s are #defined to 0 (which makes or-ing them a no-op).

On occasion, C/C++/etc. programmers might have values that consist of multiple bitfields and that valid values of those 
types might have more than one of said bitfields with values of 0, and therefore that there are legitimate reasons to 
OR together various constants that happen to be 0.  ENC_ values happen to be one of those occasions.

Given that, for cppcheck, "The goal is no false positives."

        http://sourceforge.net/apps/mediawiki/cppcheck/index.php?title=Main_Page

they either need to stop warning about that or provide a way to control which cases of ORing 0's together to warn about.
___________________________________________________________________________
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