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.
