30-10-2007, 04:42 PM
Frank Haug Wrote:The wording of 14.1 does not clarify the issue clear enough. I've discussed with several experienced persons and the common of these discussions is, that the questions only can be resolved, if someone ADDS personal interpretations. That cannot be the intension of a rule (text).
Firstly, "defensive programming" is not a misra rule. In my opinion this is a severe lack in/on the misra rule set. Although not explicitly defined its used in the rule text of 14.1 and its used in a confusing way: "Code that can be reached but may never be executed is excluded from the rule (e.g. defensive programming)".
In my tries to understand this, I refactored this sentence on following part (and nobody out of my discussions with Developers and QA Managers could give me an answer on that):
What is "code, that can be reached but (may) never be executed" ?
The provided example does not answer this question, because it shows code that "exists but never will be reached".
Maybe it helps to concretesize my intention when I re-word above sentence as follows: "Is it possible, that code can be reached but not executed ?"
Thanks in advance
Frank
My understanding of the rule is as follows:
The reachability of a code portion is given by the logic of the implementation in a given context. This is typically the body of a function. Here, reachability of a statement can be determined by evaluating the logic of control flow and its conditions.
However, when a function is used, all calls to it may use input values such that a particular portion of the code is not executed. An example that can often be found is the following: A pointer is passed to a function to access some data. In the function, before accessing the data, it is checked whether the pointer points to a valid address (e.g. is not NULL). If a NULL pointer is detected, an error is raised somehow.
The callers of the function however, check if their parameters have valid values and do not call the function if they don't. This means that during normal program execution the error code is reachable but is never executed. Nevertheless it could happen that the function may be called with a valid pointer but due to a failure (electrical hazard or another parallel process/thread memory access) the parameter value is cleared and the pointer is set to NULL or more likely, another caller is implemented that does not check its parameters (think of library functions).
The difference to unreachable code caused by control logic is the ability for the compiler to eliminate an unreachable statement during compilation such that is no longer possible to execute it. Depending on the analysis performed by the compiler, the situation sketched above could also be analysed to some extend.
May be this could help in understanding the rule!
Martin