<![CDATA[MISRA Discussion Forums - 6.15 Switch Statements]]> https://forum.misra.org.uk/ Thu, 05 Nov 2026 19:06:11 +0000 MyBB <![CDATA[15.2 and 'break's inside if-else]]> https://forum.misra.org.uk/showthread.php?tid=913 Thu, 06 Sep 2012 19:26:44 +0000 gs]]> https://forum.misra.org.uk/showthread.php?tid=913
Code:
...
switch( x )
{
case 1:
    if( y )
        {
        ...
        break;
        }
    else
        {
        ...
        break;
        }
default:
    break;
}
...

Does this code violate rule #15.2?]]>
Code:
...
switch( x )
{
case 1:
    if( y )
        {
        ...
        break;
        }
    else
        {
        ...
        break;
        }
default:
    break;
}
...

Does this code violate rule #15.2?]]> <![CDATA[Unreachable break in a case statement]]> https://forum.misra.org.uk/showthread.php?tid=906 Wed, 04 Jul 2012 08:14:21 +0000 danielb]]> https://forum.misra.org.uk/showthread.php?tid=906
Code:
switch(cond)
{
  case 0:
  {
    /* A deliberate infinite loop. */
    for ( ; ; ) { }
    
    /* Unreachable break statement. */
    break;
  }
  [ … ]
}
One MISRA checker insists on the break statement referring to rule 15.2, while the other insists that the break statement is unreachable code according to rule 14.1.

Both rules are required, however, both can not be enforced in this case. Which rule supersedes the other?]]>
Code:
switch(cond)
{
  case 0:
  {
    /* A deliberate infinite loop. */
    for ( ; ; ) { }
    
    /* Unreachable break statement. */
    break;
  }
  [ … ]
}
One MISRA checker insists on the break statement referring to rule 15.2, while the other insists that the break statement is unreachable code according to rule 14.1.

Both rules are required, however, both can not be enforced in this case. Which rule supersedes the other?]]> <![CDATA[15.1 and "switch(0) case 0:"]]> https://forum.misra.org.uk/showthread.php?tid=873 Tue, 10 Jan 2012 15:01:53 +0000 gs]]> https://forum.misra.org.uk/showthread.php?tid=873 Given the following code:
Code:
...
switch(0)
case 0:
...
does the example presented violate rule #15.1? Syntactically, the "switch(expression)" is followed by a "statement" and not necessarily a "compound statement" as stated in the rule. Therefore, can we correctly presume said code violates said rule?]]> Given the following code:
Code:
...
switch(0)
case 0:
...
does the example presented violate rule #15.1? Syntactically, the "switch(expression)" is followed by a "statement" and not necessarily a "compound statement" as stated in the rule. Therefore, can we correctly presume said code violates said rule?]]> <![CDATA[Rule 15.4 - no boolean switch expressions]]> https://forum.misra.org.uk/showthread.php?tid=821 Fri, 08 Apr 2011 13:02:18 +0000 eddieh]]> https://forum.misra.org.uk/showthread.php?tid=821
The Standard says:

Code:
switch( x == 0 )
{
    ...

is non-compliant, which seems reasonable. However, my compiler complains about:

Code:
enum_type x;

switch( x )
{
    case ENUM_A :
        do_stuff;
        break;
    default :
        /* No action */
        break;
}

Because 'x' is an enumerated type, I like to make it clear that we do_stuff for a particular subset of possible values.

What is intended interpretation of this rule? There is no explanation in the Standard.

Many thanks in advance for any comments.

Cheers,
Eddie.]]>
The Standard says:

Code:
switch( x == 0 )
{
    ...

is non-compliant, which seems reasonable. However, my compiler complains about:

Code:
enum_type x;

switch( x )
{
    case ENUM_A :
        do_stuff;
        break;
    default :
        /* No action */
        break;
}

Because 'x' is an enumerated type, I like to make it clear that we do_stuff for a particular subset of possible values.

What is intended interpretation of this rule? There is no explanation in the Standard.

Many thanks in advance for any comments.

Cheers,
Eddie.]]> <![CDATA[Implicit type conversions in switch statements]]> https://forum.misra.org.uk/showthread.php?tid=787 Tue, 02 Nov 2010 17:48:28 +0000 dcrocker]]> https://forum.misra.org.uk/showthread.php?tid=787
Code:
int8 x;
...
switch(x)
{
    case 0:      /* valid */
    case 255:    /* valid? */
    case 1L:     /* invalid, implicit cast from long to int */
        ...
}

I would expect any good static checker to report that x can never equal 255 here. But is 'case 255:' actually a MISRA 2004 rule violation? The C standard says that the switch expression x gets promoted to 'int' in this case, so the type of the case label 255 does match the type of the promoted switch expression. I can't find any MISRA rule that says that we should consider the underlying type (instead of the promoted type) of the switch variable when deciding whether a case label is allowed or not. If "case 255:" was the only case label on some code, then rule 14.1 (no unreachable code) would apply; but in this example, there is no unreachable code.]]>
Code:
int8 x;
...
switch(x)
{
    case 0:      /* valid */
    case 255:    /* valid? */
    case 1L:     /* invalid, implicit cast from long to int */
        ...
}

I would expect any good static checker to report that x can never equal 255 here. But is 'case 255:' actually a MISRA 2004 rule violation? The C standard says that the switch expression x gets promoted to 'int' in this case, so the type of the case label 255 does match the type of the promoted switch expression. I can't find any MISRA rule that says that we should consider the underlying type (instead of the promoted type) of the switch variable when deciding whether a case label is allowed or not. If "case 255:" was the only case label on some code, then rule 14.1 (no unreachable code) would apply; but in this example, there is no unreachable code.]]> <![CDATA[Rule 15.2: MISRA warning is not generated]]> https://forum.misra.org.uk/showthread.php?tid=776 Mon, 27 Sep 2010 10:47:39 +0000 vastrad]]> https://forum.misra.org.uk/showthread.php?tid=776
The Rule 15.2 says:
"An unconditional break statement shall terminate every non-empty switch clause"
i.e. The last statement in every switch clause shall be a break statement, or if the switch clause is a compound statement, then the last statement in the compound statement shall be a break statement.

I understand this as:
"In a switch clause, whatever be the path traversed by the code, there shall be one break statement at the end of every path"

In a project I have the following code for which I am not getting any MISRA warning (for case 1). If my understanding is incorrect, then somebody please correct me.

Code:
switch (variable_1)
{
  case 0:
    {
        // some code here;
        break;
    }
  case 1:
    {
        // some code here;
        if (variable_2 == 0)
        {
            break;
        }
    }
    default:
        break;
}

Best Regards,
Vinay Vastrad]]>
The Rule 15.2 says:
"An unconditional break statement shall terminate every non-empty switch clause"
i.e. The last statement in every switch clause shall be a break statement, or if the switch clause is a compound statement, then the last statement in the compound statement shall be a break statement.

I understand this as:
"In a switch clause, whatever be the path traversed by the code, there shall be one break statement at the end of every path"

In a project I have the following code for which I am not getting any MISRA warning (for case 1). If my understanding is incorrect, then somebody please correct me.

Code:
switch (variable_1)
{
  case 0:
    {
        // some code here;
        break;
    }
  case 1:
    {
        // some code here;
        if (variable_2 == 0)
        {
            break;
        }
    }
    default:
        break;
}

Best Regards,
Vinay Vastrad]]> <![CDATA[Rule 15.0 - Required or Adviosry?]]> https://forum.misra.org.uk/showthread.php?tid=684 Sat, 24 Oct 2009 18:32:34 +0000 William Forbes]]> https://forum.misra.org.uk/showthread.php?tid=684 However it does not explicitly state if this rule is "Required" or "Advisory"
Is rule 15.0 "required" or "advisory"?]]> However it does not explicitly state if this rule is "Required" or "Advisory"
Is rule 15.0 "required" or "advisory"?]]> <![CDATA[Combining case and default?]]> https://forum.misra.org.uk/showthread.php?tid=675 Fri, 07 Aug 2009 16:21:36 +0000 exoson]]> https://forum.misra.org.uk/showthread.php?tid=675
switch (err) {
case 0:
...
break;

case 1:
case 2:
case 3:
default:
...
break;
}

I am seeing code examples like this where multiple cases are being combined with default. Most compiler will simply optimize this out to a simple test for case 0. The programmers are using this as a way to identify the results they might expect. I think having the other cases in a comment would serve this as well. MISRA C does not seem to mention this.
From a test perspective I feel it is necessary to test all declared cases.
Can anyone offer a comment on this?

Scott
Validated Software]]>
switch (err) {
case 0:
...
break;

case 1:
case 2:
case 3:
default:
...
break;
}

I am seeing code examples like this where multiple cases are being combined with default. Most compiler will simply optimize this out to a simple test for case 0. The programmers are using this as a way to identify the results they might expect. I think having the other cases in a comment would serve this as well. MISRA C does not seem to mention this.
From a test perspective I feel it is necessary to test all declared cases.
Can anyone offer a comment on this?

Scott
Validated Software]]> <![CDATA[Rule 15.3 - question over wording of rule]]> https://forum.misra.org.uk/showthread.php?tid=643 Wed, 01 Apr 2009 23:53:09 +0000 CarlinB]]> https://forum.misra.org.uk/showthread.php?tid=643
Rule 15.3 states that "The final clause of a switch statement shall be the default clause."

Is the point of the rule to dictate where the default clause should be located or only to make sure that every switch statement includes a default clause?

I would agree that every switch statement should have a default clause, but I am not clear on why the rule would dictate where this clause should be located.

The rule description clearly states this is a "defensive programming" action. Being such, it makes sense that many times the end of your clause list is the appropriate place for the default clause (there to catch any unhandled case). However, there are times where the desired default behavior is the same as one of the case clauses. Furthermore, the arrangement of the case clauses is often done in some logical order (i.e. progression through a menu). It seems to me that reordering the list of cases just to satisfy this rule is unnecessary, particularly when it breaks the logical flow of the cases.

As an example, here is a switch statement that might be used to determine the appearance of a list of items displayed to a user. For this example, the desired default behavior is to display the list same as if "case 0" was the selection.

Code:
switch(itemSelected)
{
    default:
    case 0:  
    {  /* show list with first item highlighted */ } break;

    case 1:
    {  /* show list with second item highlighted */ } break;

    case n:
    {  /* show list with n-th item highlighted */ } break;
}

Logically, I feel it makes more sense to locate the default clause with the first case clause rather than moving "case 0" to the end of the clause list or repeating the contents of the "case 0" clause in the default clause.

I realize that in practice a deviation can be recorded for why this rule is not followed. But, if the real intent of the rule is to ensure a default clause is always provided then it seems the rule should be reworded to emphasize the need for a default clause and leave the location of the default clause as advisory. However, if the rule really is meant to dictate where the default clause is located, I would appreciate if someone could provide an explanation of why this location is important enough to be a "required" rule.]]>
Rule 15.3 states that "The final clause of a switch statement shall be the default clause."

Is the point of the rule to dictate where the default clause should be located or only to make sure that every switch statement includes a default clause?

I would agree that every switch statement should have a default clause, but I am not clear on why the rule would dictate where this clause should be located.

The rule description clearly states this is a "defensive programming" action. Being such, it makes sense that many times the end of your clause list is the appropriate place for the default clause (there to catch any unhandled case). However, there are times where the desired default behavior is the same as one of the case clauses. Furthermore, the arrangement of the case clauses is often done in some logical order (i.e. progression through a menu). It seems to me that reordering the list of cases just to satisfy this rule is unnecessary, particularly when it breaks the logical flow of the cases.

As an example, here is a switch statement that might be used to determine the appearance of a list of items displayed to a user. For this example, the desired default behavior is to display the list same as if "case 0" was the selection.

Code:
switch(itemSelected)
{
    default:
    case 0:  
    {  /* show list with first item highlighted */ } break;

    case 1:
    {  /* show list with second item highlighted */ } break;

    case n:
    {  /* show list with n-th item highlighted */ } break;
}

Logically, I feel it makes more sense to locate the default clause with the first case clause rather than moving "case 0" to the end of the clause list or repeating the contents of the "case 0" clause in the default clause.

I realize that in practice a deviation can be recorded for why this rule is not followed. But, if the real intent of the rule is to ensure a default clause is always provided then it seems the rule should be reworded to emphasize the need for a default clause and leave the location of the default clause as advisory. However, if the rule really is meant to dictate where the default clause is located, I would appreciate if someone could provide an explanation of why this location is important enough to be a "required" rule.]]> <![CDATA[Switches, default, and enums]]> https://forum.misra.org.uk/showthread.php?tid=362 Thu, 24 May 2007 12:38:54 +0000 ChrisNelson]]> https://forum.misra.org.uk/showthread.php?tid=362
Code:
typedef enum {
      red,
      green,
      blue
   } color_t;

   void f(color_t color) {
      switch (color) {
      case red:
         /* do something */
         break;
      case green:
         /* do something */
         break;
   }
Many compilers and certainly most lints will generate a warning when compiling the function f noting that not all enum values are handled. When the typedef and the switch are in different files, this can be quite helpful. When the enum is handled by switches in multiple source files, this structure allows the compiler to catch unmodified switches when a new enum value is added. If there was a default case in this switch, the compiler would not complain.

With that in mind, I suggest that rule 15.3 be revised by adding, \"except where the switch expression is an enum\" to the end. I might also add a advisory rule encouraging switch expressions to be enums.

Any thoughts?]]>
Code:
typedef enum {
      red,
      green,
      blue
   } color_t;

   void f(color_t color) {
      switch (color) {
      case red:
         /* do something */
         break;
      case green:
         /* do something */
         break;
   }
Many compilers and certainly most lints will generate a warning when compiling the function f noting that not all enum values are handled. When the typedef and the switch are in different files, this can be quite helpful. When the enum is handled by switches in multiple source files, this structure allows the compiler to catch unmodified switches when a new enum value is added. If there was a default case in this switch, the compiler would not complain.

With that in mind, I suggest that rule 15.3 be revised by adding, \"except where the switch expression is an enum\" to the end. I might also add a advisory rule encouraging switch expressions to be enums.

Any thoughts?]]>