Rule 15.2: MISRA warning is not generated - Printable Version +- MISRA Discussion Forums (https://forum.misra.org.uk) +-- Forum: MISRA C (https://forum.misra.org.uk/forumdisplay.php?fid=4) +--- Forum: MISRA-C: 2004 rules (https://forum.misra.org.uk/forumdisplay.php?fid=17) +---- Forum: 6.15 Switch Statements (https://forum.misra.org.uk/forumdisplay.php?fid=45) +---- Thread: Rule 15.2: MISRA warning is not generated (/showthread.php?tid=776) |
Rule 15.2: MISRA warning is not generated - vastrad - 27-09-2010 Hi All, 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) Best Regards, Vinay Vastrad Re: Rule 15.2: MISRA warning is not generated - William Forbes - 27-09-2010 The section at the beginning of the section 6.15 is considered normative and is known by Rule 15.0. Here, I think you'll find that your example breaks the rule for the syntax of a "case-clause". Note that the only legal terminating token sequences are Code: break ; Code: break ; } Code: break ; } } Re: Rule 15.2: MISRA warning is not generated - vastrad - 28-09-2010 William Forbes Wrote:The section at the beginning of the section 6.15 is considered normative and is known by Rule 15.0. If we understand the reply as "Whatever be the number of paths we traverse within a case statement, finally the case statement should end with an explicit break. It is not acceptable to have three break statements from three different paths", then should we not get a MISRA warning when we write a break statement within an if/else block? Re: Rule 15.2: MISRA warning is not generated - William Forbes - 28-09-2010 Hi, I don't quite understand your last question. However, I can say that a break statement within an if-else construct by itself is not a violation of a MISRA rule as it may be being used to break out of an iteration statement (see rule 14.6). The grammar of the C language is extended by Rule 15.0 such that not terminating the added "case-clause" as indicated means that the code does not comply with the extended grammar and hence not compliant with Rule 15.0. The reason you don't get a warning is probably because your MISRA checker is broken. What are you using? Re: Rule 15.2: MISRA warning is not generated - Lundin - 29-09-2010 You can have as many break statements you like inside your case, as long as it ends with one. The MISRA rules regarding break are there to ban "fall-through" between case statements. But come to think of it, this actually seems to be a flaw in the MISRA rules. MISRA doesn't allow more than one break inside loops (14.6) nor more than one return inside functions (14.7). But it doesn't mention multiple breaks in a switch statement. Which one of these examples is "most spaghetti"? Code: while(something) Code: int func () Code: switch(something) I think the switch spaghetti is even less readable than the two non-compliant examples. Perhaps a rule similar to 14.6 should be added, to disallow more than one break in each case, ie ban more than one exit point from each case statement? For the same reason rules 14.6 and 14.7 exist. Re: Rule 15.2: MISRA warning is not generated - William Forbes - 29-09-2010 I personally feel that MISRA-C: 1998 had this sorted with Rule 58. I think good code and design does not need break statements (except in switch statements). If you desperately need one then you can always invoke the deviation procedure! Re: Rule 15.2: MISRA warning is not generated - misra-c - 03-11-2010 The code example originally posted violates Rules 15.0 and 15.2 so a MISRA C checker would be expected to produce diagnostic messages. |