14-01-2008, 04:06 PM
Hi Frank,
The rule is about not having unreachable code.
Or
You shall only have reachable code.
There are a few cases in C in which valid syntax can give a sequence of statements in which one (or more) statements CANNOT be reached and executed. See mc2_1401.c in exemplar suite. These are unconditional control flow changes which cause the subsequent statements are unreachable. I.E. break, goto, return, if(0), if(!1).
This rule is NOT about ANY reachable code, which may include code that only executes under \"adverse\" conditions (i.e. defensive programming). No form of reachable code is excluded by this rule.
The example is an example of unreachable code in the syntax of a switch statement. It is NOT an example of defensive programming. Subsequently, TC1 enforces the syntax of a switch statement, so this example would violate Rule 15.0 – Switch Statement syntax.
This replacement rule assumes that you have a definition of unreachable.
While the compiler is not confused, having any text which appears to be valid code, but is omitted from the program risks the danger that the human reader believes that code to be executed. The human then draws incorrect assumptions from the text. If the conclusion affects the safety of the system, this is critical. Therefore avoid this risk by the mandatory removal of unreachable code.
But
a) is required under Rule 15.3
b) is required under Rule 14.10, in all cases and not \"Exclusively to catch error conditions\".
What you have written under extension 2 is NOT part of this rule. Rule 14.1 is saying nothing about reachable defensive code.
Gavin
Quote:Rule 14.1 There shall be no unreachable code.
The rule is about not having unreachable code.
Or
You shall only have reachable code.
There are a few cases in C in which valid syntax can give a sequence of statements in which one (or more) statements CANNOT be reached and executed. See mc2_1401.c in exemplar suite. These are unconditional control flow changes which cause the subsequent statements are unreachable. I.E. break, goto, return, if(0), if(!1).
This rule is NOT about ANY reachable code, which may include code that only executes under \"adverse\" conditions (i.e. defensive programming). No form of reachable code is excluded by this rule.
The example is an example of unreachable code in the syntax of a switch statement. It is NOT an example of defensive programming. Subsequently, TC1 enforces the syntax of a switch statement, so this example would violate Rule 15.0 – Switch Statement syntax.
Quote:not MISRA 2004 - extension 1: avoid unreachable code - advisory
===============================================================
reason: there only can be reachable code or unreachable code. Unreachable code is not safety critical, but it reduces transparency and maintenance, therefore it should be eliminated. Because unreachable code is not primarily dangerous, I mark it as \"advisory\".
This replacement rule assumes that you have a definition of unreachable.
While the compiler is not confused, having any text which appears to be valid code, but is omitted from the program risks the danger that the human reader believes that code to be executed. The human then draws incorrect assumptions from the text. If the conclusion affects the safety of the system, this is critical. Therefore avoid this risk by the mandatory removal of unreachable code.
Quote:not MISRA 2004 - extension 2: Defensive Programming - mandatory
==============================================================
always take
a) a default statement in a switch
b) a final else branch (in \"if - else if - else if - else\" (14.10) ... not necessary in \"if only\") EXCLUSIVELY to catch error conditions.
reason: changing code in an other part of the translation unit (maybe later) may lead into the default or final else branch and always should be caught. (also see \"6.15 Switch Statements -> Switches, default, and enums!\" Posted: Wed Jan 09, 2008 5:12 pm, by George Brown).
But
a) is required under Rule 15.3
b) is required under Rule 14.10, in all cases and not \"Exclusively to catch error conditions\".
What you have written under extension 2 is NOT part of this rule. Rule 14.1 is saying nothing about reachable defensive code.
Gavin