MISRA Discussion Forums - 8.10 The essential type model

10.3 Clarify if narrower in the title refers the the rank of the essential type

Thu, 25 Jun 2026 21:03:44 +0000

The rule 10.3 says:

Quote:The value of an expression shall not be assigned to an object with a narrower //essential type//

What does it mean to be narrower? To have a lower rank, or to have a smaller size?

For instance, on a platform where

Code:
sizeof(long) == sizeof(long long)

Is the following code compliant with rule 10.3:

Code:
long l = 0;

long long ll = 0;

l = ll; // Compliant or not?

My feeling is that it is compliant, because the word rank is not used here, while it is explicitly used in other parts of the rule, but I'm not 100% confident.

What is the UTLR of -1?

Tue, 09 Jun 2026 09:36:31 +0000

I'm attempting to determine the essential type of the following expression:

Code:
(unsigned short)1 - (unsigned short)2

This is a operation subject to arithmetic conversion (D.7.9), both operands are essentially unsigned, and the expression is an integer constant expression, so according to item 4.1, the essential type of the result is the UTLR of the result.

However, the result is a signed integer with the value -1. The following program demonstrates this:

Code:
#include 

#define TYPE(x) _Generic((x), \

    int: printf("int\n"), \

    unsigned int: printf("unsigned int\n"), \

    default: printf("other\n") \

)

int main() {

    TYPE(1u - 2u);  

    TYPE(1 - 2);  

    TYPE((unsigned short)1 - (unsigned short)2);

}

So we have to compute the UTLR of a negative value, which is not defined.

Is there an error in my reasoning, or is this a limitation in the essential type system?

Typo in Appendix C of MISRA C:2023

Mon, 17 Mar 2025 14:58:24 +0000

Appendix C (C.1.1, p. 270 (hard copy) / p. 271 (pdf)*) of MISRA C:2023 (3rd Edn, 2nd Rev., April 2023) reads:
"... as the examples below show (si and ui are 32-bit signed and unsigned integers and u8 is an 8-bit unsigned char):"

However, there is a lack of correspondence between the above-introduced unsigned char object identifier of u8 and the naming of an operand of unsigned char type in the table that follows immediately (viz. uc, columns Expression and Notes). On page 273(274) (C.2.4, a distinct sub-section of the Appendix) such an unsigned char object of similar name is indeed used (u8a), in line with the exemplary non-specific object names used in code fragments throughout the Guidelines' body of text (the naming convention introduced on p. 14).

For the sake of ease of visually perceiving the types involved in the expressions and following through the implicit conversions they undergo, it is a good decision that concise, plain names such as si, ui, and uc are used, instead of operand identifiers cluttered with numeric characters (as would be in s32(i32), u32 and u8).

Apparently, this lack of correspondence between the operand names in the table and their prior introduction in the text is inherited from the previous versions of the Guidelines (MISRA C:2012 – 3rd Edn, March 2013; 3rd Edn, 1st Rev., February 2019). Never corrected by subsequent Technical Corrigenda or Amendments to those. It is now present in MISRA C:2025 as well.

Please, consider appending the erratum, reported in this separate forum thread†, to the dedicated MISRA C Errata list maintained on the MISRA website, to keep it up-to-date and indeed a readily available single source of reference for all misprints found in MISRA C:2023, 3rd Edn, 2nd Rev.

_____

(*) Note that the text starts to disagree with the page numbering of the two documents (the electronic one and the hard copy) beginning from p. 229 onwards! This does not make favour to coherently referencing parts of the Guidelines and may lead to confusion and misunderstanding.

(†) This thread is considered the most relevant one as Appendix C is referenced mostly in there, and as there are no dedicated threads specifically aimed at the appendices, or some other general means for reporting typographical and other errors.

Explain deviation requirement

Tue, 18 Jun 2024 11:26:00 +0000

Hello, could someone explain the following deviation requirement:

"This deviation permit shall only be applied if the compiler's implementation has been verified to be consistent with the code generator's configuration (implicit or explicit)."

It is mentiond in rule 10.3, 10.4 and 10.8.
How to prove that this can be fullfilled? Could you refer to autocode?

Thanks!

Further guidance on MISRA-C 2012 Rule 10.6

Tue, 09 Apr 2024 14:29:12 +0000

MISRA-C 2012 D.3 states that UTLR/STLR rules are only applied to integer constant expressions for operators that explicitly specify this in D.7. D.7 further states that the essential type is the standard type unless otherwise listed and does not specify a non-standard essential type for sizeof.

Given the following example:

Code:
typedef unsigned int uint32_t;

typedef unsigned short uint16_t;

extern uint16_t u16;

extern uint32_t u32;

extern void foo( void );

void foo( void ) {

    uint32_t case1 = (sizeof(uint32_t) + sizeof(uint32_t)) + u16; /*Case 1*/

    uint32_t case2 = u32 + u32 + u16; /*Case 2*/

    uint32_t case3 = sizeof(uint32_t) + (sizeof(uint32_t) + u16);/*Case 3*/

    uint32_t case4 = sizeof(uint32_t) + u16 + sizeof(uint32_t); /*Case 4*/

}

Which of the cases violates Rule 10.6 while providing the rationale?

MISRA C:2012 Rule 10.8 Question

Sat, 11 Nov 2023 15:29:00 +0000

The rule 10.8 states that "The value of a composite expression shall not be cast to a different essential type category or a wider essential type".

I understand that casting to a wider type will cause incompatibilities for different compilers where int have different width, but I don't understand why we cannot cast it to a different essential type category with the same or less width.

In other words, the example

Code:
(uint32_t)(int32_t+int32_t)  /* Non-compliant */

is non-compliant, but the rationale behind this is feels unclear to me, as this code does not have inconsistency between compilers.

A possible explanation is that:
(1) despite the fact that writing like this will guarantee consistent behavior across compilers and architectures,
(2) it easily misleads an inexperienced human programmer to interpret the computation inside the "()" to be carried out in uint32_t, which is of course not the case,
so this is banned.

I want to know whether this human readability is the rational behind the first clause of the rule. Thanks for looking into this matter in advance!

MISRA C:2012 Rule 10.8 Clarification

Mon, 14 Aug 2023 13:58:22 +0000

MISRA C:2012 Rule 10.8 states "The value of a composite expression shall not be cast to a different essential type category or a wider essential type".

One example of a violation given is:

( uint32_t ) ( u16a + u16b ) /* Non-compliant - cast to wider
* essential type */

But what about:

( uint32_t ) u16a + ( uint32_t ) u16b /* Compliant? */

This kind of thing does get flagged by Polyspace 2022b as a violation of Rule 10.8, but am I correct in thinking that casting the variables before the compound operator is applied means that this not in fact a violation?

Rule 10.4 and essentially signed integer constant expressions

Tue, 19 Jan 2021 14:34:47 +0000

Rule 10.3 exception 1 allows assigning a signed integer constant expression to an essentially unsigned type, if the value can be represented in that type; u8 = 2 * 24; is allowed.
Rule 10.4 has no such exception
Expressions like u32 > 0, u8 != 0, and u32 += 1 violate rule 10.4.

Now:

uint32_t u32idem(uint32_t x) { return x; }
bool less_u32(uint32_t a, uint32_b ) { return a < b; }

if (u32 < u32idem(1)) { /* accepted by 10.3 and 10.4 */
} else if (less_u32(u32, 3)) { /* accepted by 10.3 (and 10.4) */
} else if (u32 < 4u) { /* fine by 10.4 */
} else if (u32 < 7) { /* violates 10.4 */
} else if (11u > u32) { /* ok, remove u and it's not */
} else {
switch (u32) {
case 23: /* ok */
...

Why are binary operators handled differently from assignments and switch cases? I think the exception should be the same for both 10.3 and 10.4 ?

Why is there no exception for Rule 10.4 allowing an integer constant expression to be used in a binary expression?

10.4 violation for u8b + 2

Mon, 18 Jan 2021 13:27:41 +0000

Hello MISRA Bulletin Board,

I understand mixing signed and unsigned variables in arithmetic operations can really lead to unexpected results,
but I really fail to see what is the risk in adding a constant value of 2 (SLTR of signed char) to an unsigned 8-bit (char) variable.

Could you please elaborate what can possibly go wrong in this case?

Thanks in advance.

No operators in #if

Thu, 17 Dec 2020 08:29:23 +0000

The MISRA checker I am using is rejecting operators in #if as noted in the following code.

Code:
#define TRUE 1

#define Condition1 TRUE

#define Condition2 TRUE

#if Condition1   /* Accepted */

#endif

#if !Condition1  /* Rejected */

/* Rejection is because:

Unpermitted operand to operator '!' [MISRA 2012 Rule 10.1, required]

*/

#endif

#if Condition1 && Condition2  /* Rejected */

/* Rejection is because:

Unpermitted operand to operator '&&' [MISRA 2012 Rule 10.1, required]

*/

#endif

#if Condition1 || Condition2  /* Rejected */

/* Rejection is because:

Unpermitted operand to operator '||' [MISRA 2012 Rule 10.1, required]

*/

#endif

According to the supplier, the constant '1' (or '0' when used in the same way) is being interpreted as a signed int and therefore the operators '!', '&&' and '||' cannot be used with it.

Is the checker's interpretation correct?

Is it possible to define your own Boolean types?

Mon, 06 Jul 2020 07:44:48 +0000

Hello,

I want to know if it is possible to define a Boolean type and do not use the one defined in the stdbool.h. Can I define Boolean like this:

Code:
typedef uint8_t boolean;

and

Code:
#define TRUE 0x1

and

Code:
#define FALSE 0x0

? And If I define Boolean in this way, what operations, which if done using standard booleans would I violate?

Sorry in advance If the question is not too clear and If I made some mistake.

Essential type of ~(uint16_t)0x30

Thu, 09 Apr 2020 16:37:49 +0000

What is the essential type of "~(uint16_t)0x30" ?

Going by Appendix D "Bitwise complement":
* The operand is essentially unsigned
* The operand is an integer constant expression
* The result of "~(uint16_t)0x30" is -49 of standard type int (assuming int is 32 bits and twos complement).
* The UTLR of -49 is ill-defined.

Option 1: If the resulting constant is negative, convert it to the unsigned type corresponding to the expression's standard type, then use the UTLR of that converted value. This would result in "~(uint16_t)0x30" having essential type "unsigned int" (same as without the cast to uint16_t).

Option 2: If the resulting constant is negative, treat the expression as if it was non-constant, using the essential type of the operand instead. This would result in "~(uint16_t)0x30" having essential type "uint16_t" (same as if 0x30 wasn't a compile-time constant).

Option 3: If the resulting constant is negative, use the standard type for the essential type. This would result in "~(uint16_t)0x30" having essential type "signed int".

This also affects other constant expressions producing negative values after integral promotion, e.g. "(uint16_t)300u - (uint16_t)301u".

10.3 "promoted type" of controlling expression

Thu, 27 Feb 2020 14:45:49 +0000

What exactly is meant by Rule 10.3 using "promoted type" in "The conversion of the constant expression in a switch statement’s case label to the promoted type of the controlling expression." ?
Using the promoted type kinds of contradicts the rule title, which is using essential types.

The following examples assume 10.3 uses the standard C type (after integer promotions) for the controlling expression.
Does the promotion also apply to the case labels, or do we keep using the essential type there? Assuming we keep using the essential type for case labels, that leads to some surprising violations:

Code:
uint8_t a = 1;

switch (a) { // type promoted to "signed int"

  case 1u:  // 10.3 violation because 1u is essentially unsigned, but the controlling expression is promoted to an essentially signed type?

  case -200: // compliant with 10.3, even though the case is impossible to reach due to the sign mismatch?

      break;

}

Is there a way to write the following switch that is compliant on both 16-bit and 32-bit machines?

Code:
uint16_t num = ...;

switch (num >> 1u) { // uint16_t promotes to 'signed int' or 'unsigned int' depending on "sizeof(uint16_t) == sizeof(int)"

  case 1u:   // 10.3 violation where sizeof(int)>2, because the controlling expression is promoted to an essentially signed type?

  case (uint16_t)2u:  // 10.3 violation where sizeof(int)>2, because the controlling expression is promoted to an essentially signed type?

  case 2:  // I guess signed literals work in all cases, thanks to exception 3.

      break;

}

It would make more sense to use the essential type for both controlling expression and labels; or use the standard type for both.

Rule 10.6 An expression shall not be assigned to a wider type

Mon, 27 Jan 2020 23:47:51 +0000

The full rule title is:

Quote:The value of a composite expression shall not be assigned to an object with a wider essential type

I am having a lively debate with my scanner vendor about the quality of their scans. The following example code is generating the commented violation:
[code]
static inline uint32_t bit32 (uint32_t pos)
{
static const uint32_t mask = 31U;
static const uint32_t one = 1U;

// Event misra_c_2012_rule_10_6_violation: Assigning composite expression "1U

Rule 10.3 - Bitfield narrower essential type

Thu, 24 Oct 2019 06:01:26 +0000

Hello,

Assuming that I have the following structure and enum:

Code:
typedef struct s{

  unsigned int a:5;

  unsigned int b:1;

  unsigned int c:1;

} s;

typedef enum e{

  ZERO = 0,

  ONE = 1,

  TWO = 2,

  THREE = 3

} e;

Why does the following code trigger rule 10.3?

Code:
s fcn(void)

{

  s test;

  test.a = (unsigned int) THREE;

  return test;

}