MISRA warning 12.4: integer conversion resulted in truncation (negation operation)

Question

In a huge macro I have in a program aimed for a 16-bit processor, the following code (simplified) appears several times:

typedef unsigned short int  uint16_t;
uint16_t var;
var = ~0xFFFF;

MISRA complains with the warning 12.4: integer conversion resulted in truncation. The tool used to get this is Coverity.

I have checked the forum but I really need a solution (instead of changing the negation by the actual value) as this line is inside a macro with varying parameters.

I have tried many things and here is the final attempt which fails also:

var = (uint16_t)((~(uint16_t)(0xFFFFu))&(uint16_t)0xFFFFu);

(the value 0xFFFF is just an example. In the actual code, the value is a variable which can take whatever value (but 16 bits))

Do you have any other idea please? Thanks.

EDIT:

I have tried then to use 32bits value and the result is the same with the following code:

typedef unsigned int uint32_t; 
uint32_t var; 
var = (uint32_t)(~(uint32_t)(0xFFFF0000u));

Answer 1

Summary:

Assuming you are using a static analyser for MISRA-C:2012, you should have gotten warnings for violations against rule 10.3 and 7.2.

Rule 12.4 is only concerned with wrap-around of unsigned integer constants, which can only occur with the binary + and - operators. It seems irrelevant here.

---

The warning text doesn't seem to make sense for neither MISRA-C:2004 12.4 nor MISRA-C:2012 12.4. Possibly, the tool is displaying the wrong warning.

There is however a MISRA:2012 rule 10.3 that forbids to assign a value to a variable that is of a smaller type than intended in the expression.

To use MISRA terms, the essential type of ~0xFFFF is unsigned, because the hex literal is of type unsigned int. On your system, unsigned int is apparently larger than uint16_t (int is a "greater ranked" integer type than short in the standard 6.3.1.1, even if they are of the same size). That is, uint16_t is of a narrower essential type than unsigned int, so your code does not conform to rule 10.3. This is what your tool should have reported.

The actual technical issue, which is hidden behind the MISRA terms, is that the ~ operator is dangerous because it comes with an implicit integer promotion. Which in turn causes code like for example

uint8_t x=0xFF; 
~x << n; // BAD, always a bug

to invoke undefined behavior when the value 0xFFFFFF00 is left shifted.

It is therefore always good practice to cast the result of the ~ operator to the correct, intended type. There was even an explicit rule about this in MISRA 2004, which has now merged into the "essential type" rules.

In addition, MISRA (7.2) states that all integer constants should have an u or U suffix.

MISRA-C:2012 compliant code would look like this:

uint16_t var;
var = (uint16_t)~0xFFFFu;

or overly pedantic:

var = (uint16_t)~(uint16_t)0xFFFFu;

Answer 2

When the compiler looks at the right side, first it sees the literal 0xFFFF. It is automatically promoted to an integer which is (obvious from the warning) 32-bit in your system. Now we can imagine that value as 0x0000FFFF (whole 32-bit). When the compiler does the ~ operation on it, it becomes 0xFFFF0000 (whole 32-bit). When you write var = ~0xFFFF; the compiler in fact sees var = 0xFFFF0000; just before the assign operation. And of course a truncation happens during this assignment...