MISRA Discussion Forums

Full Version: 10.3 and essential type of & expression
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Would the following examples be compliant with rule #10.3?
Code:
void foo(void) {
  uint8_t u8a = getCode();
  
  sint32_t s32a = u8a & 0xFF;    // here
}

Would the following examples be non-compliant with rule #10.3?
Code:
void foo(void) {
  uint8_t u8a = getCode();
  
  uint8_t u8b = u8a & 0xFF;    // here
}
This discussion assumes the following types.
Code:
typedef unsigned char uint8_t;
typedef signed int sint32_t;
and that signed short has 16 bits.

The essential type of u8a is "unsigned char", whereas the essential type of 0xFF is "signed short" (see Appendix D.6)
Therefore "u8a & 0xFF" will violate both
Rule 10.1 RH operand of & is signed
and
Rule 10.4 both operands do not have the same essential type category

Appendix D.7 explains that if both operands do not have the same signedness the resulting essential type of the operation is the standard C type for that operation.

According to the C standard the usual arithmetic operations are performed on the operands.
u8a is promoted to a C standard type of "signed int" - assuming the above type definitions
0xFF has a C standard type of "signed int"

Therefore both the resultant C standard type and the essential type is "signed int".

Code:
sint32_t s32a = u8a & 0xFF;
The assignment will occur from the essential type of "signed int" to "signed int", which is compliant with 10.3.

Code:
uint8_t u8b = u8a & 0xFF;
An assigning conversion will occur from the essential type of "signed int" to "unsigned char". This violates rule 10.3 because the conversion is to a type of a different essential type category.