MISRA Discussion Forums

Full Version: Let me confirm the requirement of Rule 16.1
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
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,
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.
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?
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?
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.
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.
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