MISRA Discussion Forums

Full Version: Rule 6-4-5 Is return as last statement of a switch-clause also compliant to this rule?
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Rule 6-4-5 requires an unconditional throw or break statement to terminate every non‑empty switch-clause.

But what about a return statement like in the example below.

Code:
switch ( x )
{
case 0:
   return;   // Compliant or non-compliant?
case 1:      // Compliant - empty drop through
   case 2:   // allows a group
   break;    // Compliant
case 3:
   throw;    // Compliant
case 4:
   a = b;
             // Non-compliant - non empty drop through
default:
   ;         // Non-compliant – default must also have "break"
}
The return statement for case 0: avoids an unintentional fall-through to next switch-clause.

For that reason an unconditional return at end of a switch-clause should make the switch-clause also compliant to this rule.

Is return as last statement of a switch-clause also compliant to this rule?
If you use that more than once you break rule 6-6-5, so what´s the point?
We use PC-lint / FlexeLint and in future PC-lint Plus / FlexeLint Plus for static code analysis and additionally MISRA C++:2008 compliance checking.

We have nearly all MISRA C++ rules active on checking, but not rule 6-6-5 as this rule is definitely counterproductive regarding quality of code. In most cases it is much better to exit a function using return once detecting that it can further process then build a large if tree, especially on functions of return type void.

So in our thousands of C++ source code files there are thousands of multiple returns within a function and there are several hundreds within a switch statement, too.

Rule 6-4-5 and of course also rule 6-4-3 are a problem on compliance checking with rule 6-6-5 being not applied if the usage of a return is not compliant (acceptable), just usage of break or throw as last statement of a switch-clause. It is important for us that switch statements are checked for being well-formed and for an unintentional fall-through from one switch-clause to next switch-clause.

We discussed this issue already with support of Gimpel (producing PC-lint / FlexeLint). One suggestion was inserting below line with return one more line with break. But the break is unreachable and therefore results in a message because of rule 0-1-1. The break after return is also bad for code coverage as this unreachable statement results in never getting 100% code coverage by the coverage tests.

Another suggestion was to split the compliance checking for the rules 6-4-3 and 6-4-5 up to 2 error numbers per rule. One error number checks for missing break and missing throw at end of a switch-clause, but does not output an error message if a return exists as last statement, and the other error number is output if a switch-clause ends with a return. This would make it possible to suppress the error for switch-clause ending with return, but have the other error number for also missing break / throw still enabled.

But best would be for all of us not using rule 6-6-5 if a return as last statement of a switch-clause is also compliant for rule 6-4-3 and 6-4-5.
Having multiple returns in a function violates 6-6-5 - which is required, so you cannot have a return in a case clause
We write application code for devices used in power plants, substations, etc. which must be 100% MISRA C++ compliant because we (and not our customers) want a high safety on code development.

But we write also code for device communication stacks and for applications running on Windows computers which must not be 100% MISRA C++ compliant, but of course should be also well coded as much as possible. We have defined which MISRA C++ rules are not used in code of software which must not be 100% MISRA C++ according to our own definition because of being counterproductive on developing communication stacks and GUI applications on which also C++11 and C++14 extensions are used not covered by MISRA C++:2008 at all.

There are just a few rules ignored for software which must not be 100% MISRA C++ compliant according to our own definition. One of these ignored rules is rule 6-6-5. But rule 6-4-5 is used as an unintentional fall through is never good in code of any software.

So let us think a rule 6-6-5 would not exist in MISRA C++:2008, would the existence of return as last statement of a switch-clause be compliant for rule 6-4-5?
We'd agree that the basic principle is 'no unintended fall through'. So if 6-6-5 is deviated, then a return would be acceptable at the end of a switch-clause - with a deviation of 6-4-5 as well