MISRA Discussion Forums
10.3 and essential type of & expression - Printable Version

+- MISRA Discussion Forums (https://forum.misra.org.uk)
+-- Forum: MISRA C (https://forum.misra.org.uk/forumdisplay.php?fid=4)
+--- Forum: MISRA C:2012 and MISRA C:2023 guidelines (https://forum.misra.org.uk/forumdisplay.php?fid=21)
+---- Forum: 8.10 The essential type model (https://forum.misra.org.uk/forumdisplay.php?fid=165)
+---- Thread: 10.3 and essential type of & expression (/showthread.php?tid=1205)

10.3 and essential type of & expression - lovewar - 15-10-2015

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
}


Re: 10.3 and essential type of & expression - misra-c - 29-10-2015

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.