<![CDATA[MISRA Discussion Forums - 4.9 Statements]]> https://forum.misra.org.uk/ Tue, 10 Nov 2026 11:50:26 +0000 MyBB <![CDATA[Rule 9.5.1 - Missing definitions]]> https://forum.misra.org.uk/showthread.php?tid=1759 Tue, 02 Dec 2025 08:55:55 +0000 cgpzs]]> https://forum.misra.org.uk/showthread.php?tid=1759
The old MISRA C++:2008 rules did precisely define these concepts before they were used.

So I think MISRA C++:2023 should do the same.]]>
The old MISRA C++:2008 rules did precisely define these concepts before they were used.

So I think MISRA C++:2023 should do the same.]]> <![CDATA[9.4.2 assert(false) in default clause, compliant?]]> https://forum.misra.org.uk/showthread.php?tid=1740 Tue, 03 Jun 2025 19:01:41 +0000 cgpzs]]> https://forum.misra.org.uk/showthread.php?tid=1740
MISRA C++:2023 Rule 9.4.2 provides a number of requirements on switch statements, in particular that every branch shall be unconditionally terminated.

Assuming that assertions are always enabled (also in Release builds), would this code be compliant with 9.4.2?

Code:
enum class Foo
{
  a,
  b
};

int get(Foo f)
{
  switch(f)
  {
    case Foo::a: { return 123; }
    case Foo::b: { return 321; }
    default: { assert(false && "Unreachable"); }
  }
}

assert(false) leads to calling the assert_handler function, which is marked [[noreturn]], so it would fall under requirement 5f of the rule. Would you agree?

Thanks!]]>
MISRA C++:2023 Rule 9.4.2 provides a number of requirements on switch statements, in particular that every branch shall be unconditionally terminated.

Assuming that assertions are always enabled (also in Release builds), would this code be compliant with 9.4.2?

Code:
enum class Foo
{
  a,
  b
};

int get(Foo f)
{
  switch(f)
  {
    case Foo::a: { return 123; }
    case Foo::b: { return 321; }
    default: { assert(false && "Unreachable"); }
  }
}

assert(false) leads to calling the assert_handler function, which is marked [[noreturn]], so it would fall under requirement 5f of the rule. Would you agree?

Thanks!]]> <![CDATA[9.4.2 - Requirement about the default clause]]> https://forum.misra.org.uk/showthread.php?tid=1737 Tue, 20 May 2025 10:03:26 +0000 cgpzs]]> https://forum.misra.org.uk/showthread.php?tid=1737
Rule 9.4.2 requires every switch statement to have a default clause, to match handling of if/else. However, unlike an if/else statement, this has a very serious implication: it prevents the compiler from warning about explicitly unhandled enumerators:

Code:
enum class Enum
{
  A,
  B,
  C  // newly added
};

// some client code, far away from the Enum declaration
int process(Enum e)
{
  switch(e)
  {
    case Enum::A: { return 123; }
    case Enum::B: { return 321; }
    // Oops, client code does not realize they should handle Enum::C, compiler didn't warn!
    default: { return 0; }
  }
}

One could put a runtime assertion in the `default` clause, but it only shifts the problem to the right. A problem that would have been caught at compile time can now only be caught at runtime. We should catch as many defects as possible at compile time.

One can also enable -Wswitch-enum, but this is not always desirable. Sometimes one explicitly wants the switch to be non-exhaustive, and can express that via the "default" clause. With the warning, one needs to introduce non-compliant inline suppressions with compiler-specific pragmas. Or one must explicitly list all the unwanted labels and fall-through the default case, polluting the code with non-interesting code paths.

Here we are balancing two risks:

1. The risk of not handling a valid enumerator (as above).
2. The risk of not handling an non-enumerator int casted into an Enum (as per the Rationale), in the spirit of defensive programming.

Questions: has Risk 1 been considered by MISRA? Is there evidence suggesting that Risk 2 is more likely to happen than Risk 1, and we should therefore prioritize it instead?

Thanks!]]>
Rule 9.4.2 requires every switch statement to have a default clause, to match handling of if/else. However, unlike an if/else statement, this has a very serious implication: it prevents the compiler from warning about explicitly unhandled enumerators:

Code:
enum class Enum
{
  A,
  B,
  C  // newly added
};

// some client code, far away from the Enum declaration
int process(Enum e)
{
  switch(e)
  {
    case Enum::A: { return 123; }
    case Enum::B: { return 321; }
    // Oops, client code does not realize they should handle Enum::C, compiler didn't warn!
    default: { return 0; }
  }
}

One could put a runtime assertion in the `default` clause, but it only shifts the problem to the right. A problem that would have been caught at compile time can now only be caught at runtime. We should catch as many defects as possible at compile time.

One can also enable -Wswitch-enum, but this is not always desirable. Sometimes one explicitly wants the switch to be non-exhaustive, and can express that via the "default" clause. With the warning, one needs to introduce non-compliant inline suppressions with compiler-specific pragmas. Or one must explicitly list all the unwanted labels and fall-through the default case, polluting the code with non-interesting code paths.

Here we are balancing two risks:

1. The risk of not handling a valid enumerator (as above).
2. The risk of not handling an non-enumerator int casted into an Enum (as per the Rationale), in the spirit of defensive programming.

Questions: has Risk 1 been considered by MISRA? Is there evidence suggesting that Risk 2 is more likely to happen than Risk 1, and we should therefore prioritize it instead?

Thanks!]]> <![CDATA[Rule 9.3.1 - iteration statement followed by 'try']]> https://forum.misra.org.uk/showthread.php?tid=1734 Fri, 28 Mar 2025 06:19:27 +0000 mstaron]]> https://forum.misra.org.uk/showthread.php?tid=1734
class Exception{};
void f(int i)
{
    while(i) try {             // Non-compliant
        //...
    } catch(Exception e){
    }
}

I think this is non-compliant with the Rule 9.3.1, because 'try' is not a compound statement. However, accordingly to the standard 'try' should be always followed by a compound statement if it is inside a function. This code seems to be clear, so maybe this case could be added as an exception in the future versions of MISRA C++ standard.]]>
class Exception{};
void f(int i)
{
    while(i) try {             // Non-compliant
        //...
    } catch(Exception e){
    }
}

I think this is non-compliant with the Rule 9.3.1, because 'try' is not a compound statement. However, accordingly to the standard 'try' should be always followed by a compound statement if it is inside a function. This code seems to be clear, so maybe this case could be added as an exception in the future versions of MISRA C++ standard.]]> <![CDATA[9.4.2 - Why C-style enums are exempted from requiring a default clause?]]> https://forum.misra.org.uk/showthread.php?tid=1699 Thu, 22 Aug 2024 18:03:16 +0000 cgpzs]]> https://forum.misra.org.uk/showthread.php?tid=1699
This is however not required when using C-style enums, i.e. unscoped and without underlying type. Presumably because it's Undefined Behavior to cast an int out-of-range to a C-style enum, whereas it's well-defined behavior for "C++ enums". Since UB is assumed to not happen, one can assume that a C-style enum has a valid value.

However, there's a subtlety. The "range" of a C-style enum is not just the list of valid enumerators, but the smallest bitset that contains all enumerators.

So for example:

Code:
enum Foo
{
   a = 0,
   b = 1,
   c = 2,
   d = 3
};

The following code is **not** Undefined Behavior, because the valid range of this enum is 0-7 (2^3 - 1).

Code:
enum Foo x = static_cast<Foo>(7);

So I'd argue that defensive programming still applies here and a "default" case would still be needed.

What do you think?]]>
This is however not required when using C-style enums, i.e. unscoped and without underlying type. Presumably because it's Undefined Behavior to cast an int out-of-range to a C-style enum, whereas it's well-defined behavior for "C++ enums". Since UB is assumed to not happen, one can assume that a C-style enum has a valid value.

However, there's a subtlety. The "range" of a C-style enum is not just the list of valid enumerators, but the smallest bitset that contains all enumerators.

So for example:

Code:
enum Foo
{
   a = 0,
   b = 1,
   c = 2,
   d = 3
};

The following code is **not** Undefined Behavior, because the valid range of this enum is 0-7 (2^3 - 1).

Code:
enum Foo x = static_cast<Foo>(7);

So I'd argue that defensive programming still applies here and a "default" case would still be needed.

What do you think?]]> <![CDATA[MISRA C++ 9.6.2]]> https://forum.misra.org.uk/showthread.php?tid=1695 Sat, 06 Jul 2024 02:20:54 +0000 gdavis]]> https://forum.misra.org.uk/showthread.php?tid=1695 My question is about the third example for MISRA C++ 2023 Rule 9.6.2: "A goto statement shall reference a label in a surrounding block".

void f3(int32_t i, int32_t x, int32_t y)
{
  switch( i )
  {                                   // statement A
    case 0:
      if ( x < y )
        goto L3;                      // Non-compliant
      break;
    case 1:
    L3:
      break;
  }
}

I am not sure why this is non-compliant. In terms of the amplification of the rule, "A goto statement shall be enclosed in a statement that directly encloses its reference label", statement A is the compound statement as shown above. I believe the goto statement is enclosed within statement A, and statement A directly-encloses the reference label (L3).

The MISRA C 2012 and MISRA C 2023 versions of the equivalent rule 15.3 provide a different amplification that directly addresses this: "A switch-clause that does not consist of a compound statement is treated as if it were a block"

Please let me know what you think. Thank you.]]> My question is about the third example for MISRA C++ 2023 Rule 9.6.2: "A goto statement shall reference a label in a surrounding block".

void f3(int32_t i, int32_t x, int32_t y)
{
  switch( i )
  {                                   // statement A
    case 0:
      if ( x < y )
        goto L3;                      // Non-compliant
      break;
    case 1:
    L3:
      break;
  }
}

I am not sure why this is non-compliant. In terms of the amplification of the rule, "A goto statement shall be enclosed in a statement that directly encloses its reference label", statement A is the compound statement as shown above. I believe the goto statement is enclosed within statement A, and statement A directly-encloses the reference label (L3).

The MISRA C 2012 and MISRA C 2023 versions of the equivalent rule 15.3 provide a different amplification that directly addresses this: "A switch-clause that does not consist of a compound statement is treated as if it were a block"

Please let me know what you think. Thank you.]]>