Let me confirm the requirement of Rule 16.1

[nakagawat]

Dear All,

Is the following code the violation of Rule 16.1?
The code has statements after the first break statement in case 10.

// from here
typedef unsigned int uint32_t;
extern uint32_t func_a( uint32_t x );
uint32_t func_a( uint32_t x )
{
uint32_t rtn = 0;
switch( x )
{
case 10:
break;
rtn = 50; /* Rule 16.1 violation? */
break;
default:
break;
}
return rtn;
}
// to here

Best regards,

[Steve Montgomery]

In my opinion, this code complies with Rule 16.1. The syntax given in Rule 16.1 says that a switch-clause is a statement-list-opt followed by a break. I can't see anything in the rule that prevents a break from appearing within a statement-list-opt.

Of course, the example does violate Rule 2.1 because the code following the first break is unreachable.

[nakagawat]

I would like to have a formal answer to my question.
Would you please answer my question on behalf of the MISRA C Working Group?

In addition to my first question, I think that this is a pitfall of Rule 16.1 as the code
is far from well-formed.
How do you think about this?

[nakagawat]

I would like to have a formal answer to my question.
Would you please answer my question on behalf of the MISRA C Working Group?

In addition to my first question, I think that this is a pitfall of Rule 16.1 as the code
is far from well-formed.
How do you think about this?

[Steve Montgomery]

I agree that the code isn't well formed. Rule 15.4 prevents more than one break or goto from terminating a loop. Rule 15.5 prevents more than one return from a function. So maybe it is anomalous that there is no rule to prevent more than one break or goto from terminating a switch-clause.

In the example you gave, Rule 2.1 was able to detect the poor structure. However, I think there are other ways in which more than one break can be used to terminate a switch-clause without violating any rules. For example:

Code:

switch( x )
{
case 10:
if (y == 10) {
  rtn = 20;
  break;
}
rtn = 50;
break;
default:
break;
}
return rtn;
}

In MISRA C:2004, break, goto and possibly return were not allowed to appear within the body of a switch statement so neither this example nor your example would be permitted. That restriction seems to have been removed in MISRA C:2012 but it isn't mentioned in the rule mapping (https://misra.org.uk/forum/viewtopic.php?f=241&t=1256) which makes me wonder whether it was intended.

I cannot give a formal answer because I don't represent the MISRA C Working Group. We will need to wait for the formal response.

[Steve Montgomery]

I agree that the code isn't well formed. Rule 15.4 prevents more than one break or goto from terminating a loop. Rule 15.5 prevents more than one return from a function. So maybe it is anomalous that there is no rule to prevent more than one break or goto from terminating a switch-clause.

In the example you gave, Rule 2.1 was able to detect the poor structure. However, I think there are other ways in which more than one break can be used to terminate a switch-clause without violating any rules. For example:

Code:

switch( x )
{
case 10:
if (y == 10) {
  rtn = 20;
  break;
}
rtn = 50;
break;
default:
break;
}
return rtn;
}

In MISRA C:2004, break, goto and possibly return were not allowed to appear within the body of a switch statement so neither this example nor your example would be permitted. That restriction seems to have been removed in MISRA C:2012 but it isn't mentioned in the rule mapping (https://misra.org.uk/forum/viewtopic.php?f=241&t=1256) which makes me wonder whether it was intended.

I cannot give a formal answer because I don't represent the MISRA C Working Group. We will need to wait for the formal response.

[misra-c]

The MISRA-C working group agrees with the response from Steve Montgomery that your example is compliant with rule 16.1, but violates rule 2.1