+- MISRA Discussion Forums (https://forum.misra.org.uk)
+-- Forum: MISRA C (https://forum.misra.org.uk/forumdisplay.php?fid=4)
+--- Forum: MISRA C:2012 and MISRA C:2023 guidelines (https://forum.misra.org.uk/forumdisplay.php?fid=21)
+---- Forum: 8.16 Switch statements (https://forum.misra.org.uk/forumdisplay.php?fid=171)
+---- Thread: Let me confirm the requirement of Rule 16.1 (/showthread.php?tid=1314)
Let me confirm the requirement of Rule 16.1 - nakagawat - 20-02-2017
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,
Re: Let me confirm the requirement of Rule 16.1 - Steve Montgomery - 20-02-2017
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.
Re: Let me confirm the requirement of Rule 16.1 - nakagawat - 23-02-2017
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?
Re: Let me confirm the requirement of Rule 16.1 - nakagawat - 23-02-2017
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?
Re: Let me confirm the requirement of Rule 16.1 - Steve Montgomery - 24-02-2017
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.
Re: Let me confirm the requirement of Rule 16.1 - Steve Montgomery - 24-02-2017
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.
Re: Let me confirm the requirement of Rule 16.1 - misra-c - 30-03-2017
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