01-07-2013, 12:21 PM
The omission is quite deliberate!
Despite the logic of a simple, clear rule, the Working group were finding evidence that users were circumventing MISRA C:2004 rule 13.3 with constructs that were no "safer" than using the equality operator. The workaround was within the letter of the Rules, but quite clearly against the spirit - but the result was less maintainable code.
In MISRA C:2012, Directive 1.1 covers some of the generic aspects of using floating point - and as discussed in that Directive, there are many relevant issues and a project must decide how they wish to monitor the use of floating-point within the code produced by that project. Unfortunately there is no language subset that can be produced which avoids these issues.
Directive 4.1 also gives guidance on run-time failures - of which testing a floating-point number for equality is a likely candidate.
Despite the logic of a simple, clear rule, the Working group were finding evidence that users were circumventing MISRA C:2004 rule 13.3 with constructs that were no "safer" than using the equality operator. The workaround was within the letter of the Rules, but quite clearly against the spirit - but the result was less maintainable code.
In MISRA C:2012, Directive 1.1 covers some of the generic aspects of using floating point - and as discussed in that Directive, there are many relevant issues and a project must decide how they wish to monitor the use of floating-point within the code produced by that project. Unfortunately there is no language subset that can be produced which avoids these issues.
Directive 4.1 also gives guidance on run-time failures - of which testing a floating-point number for equality is a likely candidate.
Posted by and on behalf of the MISRA C Working Group