Rule 10.5 clarification

[misra-c]

"The description of rule 10.5 mentions that the operators must be applied to "small integer types" for the casts to be required. The types unsigned char and unsigned short are mentioned explicitly. What if char, short, and int are all the same size on the machine? In that case is OK to not perform the required cast? This really comes down to whether or not we should be checking for the unsigned char and unsigned short types explicitly or instead should check for all types which have a narrower type than int.

"One of the cornerstones of MISRA C is to make sure the C code is fully portable. This is perhaps the biggest concern of MISRA-C, so the rules should be the same no matter machine."





The primary aim of MISRA C is to promote "safety" – portability is a secondary concern. Reliance on implementation defined behaviour can compromise safety and should therefore be avoided wherever possible.

The intention of Rule 10.5 is two-fold:

• a) to eliminate implementation defined behaviour
  b) to eliminate reliance on integral promotion - an aspect of C which is confusing and rarely understood

There is a case for suggesting that Rule 10.5 should be applied to operands of any type, and not simply to operands with an underlying type which is a "small integer type". This is something that will be considered for a future release of the MISRA C Guidelines.

"Also, by definition of the C standard's integer promotion rules, unsigned char and unsigned short always have lesser "integer conversion rank" than int, and the type will be converted to int no matter what size char/short have on your machine. Note the danger here: "int", not unsigned int. So there could possibly be a change of signedness."

This statement is not correct. Operands of type unsigned char and unsigned short will only undergo integral promotion to signed int if the types are "smaller" than type int. If char, short and int are all implemented in the same number of bits, unsigned char and unsigned short will be promoted to unsigned int.

"Now what happens is that on this machine 0x1234U can technically be either an unsigned char, unsigned short, or an unsigned int. >From the misra spec, we chose the "smallest unsigned integer type that is capable of representing its value", unsigned char. So in this case the underlying type of the expression is unsigned char but the underlying type of u16r is unsigned int, therefore a diagnostic is issued. If instead of explicitly checking for unsigned char or unsigned short, we check the size of the types, then the problem goes away."

If char, short and int are all implemented in the same size, either one of them could be described as "the smallest integer type" (although char is always the type of lowest rank). There is no violation of Rule 10.5 here.

[quote="c-addison"]
"Another example of where the size of an int matters is the following case:
typedef int uint16_t;
uint16_t u16r, u16a;
u16r = ( u16a > 4; /* Not compliant */

This example is compliant on a machine with a 16 bit int because the underlying type of (u16a