Rule 10.1 Small integer type operands of bitwise operators

[jeromeb]

My static analyser tool throws a warning when small unsigned integer (short or char) operand is used with bitwise operator.

Code:

u16a = (uint16_t) ~u16b;

Static analyser warning : "Negative values cannot be stored as unsigned short. Coercing them to unsigned short can cause data loss or sign change."
Associated weakness : http://cwe.mitre.org/data/definitions/192.html and/or http://cwe.mitre.org/data/definitions/704.html

If I bypass integral promotion with cast to a widening type, the warning disappears;

Code:

u16a = (uint16_t) ~((unsigned int)u16b);

In ISO C99 draft 2007 (http://www.open-std.org/JTC1/SC22/WG14/w.../n1256.pdf) section J.3.5 "implementation-defined behavior", last item is :

The results of some bitwise operations on signed integers (6.5).

In MISRA C 2012, section 8.10, rule 10.1, Rationale item 6 :

Shift and bitwise operations should only be performed on operands of essentially unsigned type. The numeric value resulting from their use on essentially signed types is implementation-defined.

I don't understand why use of essentially type operands with bitwise operators can be implementation dependant while operators beahaviors are defined for standard type. In ISO C99, beahavior of bitwise operators is defined for standard type. I suppose after integral promotion ? Then, if small unsigned integers are used as operand with bitwise operators, operator works systematically with signed int after integral promotion. The behavior is implementation-dependant (two's or one's complement implementation can produce different results). Then, even with expected essentially type, I can obtain an implementation beahavior, no ?

Have I a bad interpretation of all standards (MISRA C, ISO C99, CWE, etc.) ?

[misra-c]

You are correct in saying that small unsigned types are promoted to a "signed int" standard type, but have an essentially unsigned type. This means that ~ on unsigned types is allowed by MISRA-C:2012, yet would produce different values depending on whether your implementation is one’s or two’s bit complement implementation.

This is only an issue if the resultant value is treated as a signed value, otherwise the bit pattern is consistent with what a user would expect. Any attempt to use the value of the result in an essentially signed context will produce a violation of rule 10.1, 10.3 or 10.4.

[jeromeb]

Ok, thank you very much for this answer.
I am agree with you : using a unsigned value in a signed integer type after integral promotion is not a problem.
But I had doubts after reading ISO C standard and, especially, after run our static analysis tool (that it throws a warning).
I think that :

• ISO C standard is not enough precise (bitwise operators have "implementation-defined behavior" on signed integers values and not on signed integers type
  
• Static analysis tool throws a false positive warning (it known that the value is necessarily unsigned) because the essentially type is explicit (an unsigned integer).

Are you agree with that ?