Posts: 117
Threads: 25
Joined: Apr 2016
Reputation:
0
If you use that more than once you break rule 6-6-5, so what´s the point?
<t></t>
Posts: 5
Threads: 2
Joined: Sep 2011
Reputation:
0
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.
Posts: 252
Threads: 1
Joined: Jun 2008
Reputation:
6
Having multiple returns in a function violates 6-6-5 - which is required, so you cannot have a return in a case clause
Posted by and on behalf of
the MISRA C++ Working Group
Posts: 5
Threads: 2
Joined: Sep 2011
Reputation:
0
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?
Posts: 252
Threads: 1
Joined: Jun 2008
Reputation:
6
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
Posted by and on behalf of
the MISRA C++ Working Group