+- MISRA Discussion Forums (https://forum.misra.org.uk)
+-- Forum: MISRA C (https://forum.misra.org.uk/forumdisplay.php?fid=4)
+--- Forum: MISRA-C: 2004 rules (https://forum.misra.org.uk/forumdisplay.php?fid=17)
+---- Forum: 6.13 Control Statement Expressions (https://forum.misra.org.uk/forumdisplay.php?fid=40)
+---- Thread: Does 13.7 apply to ALL invariant Boolean expressions? (/showthread.php?tid=203)
Does 13.7 apply to ALL invariant Boolean expressions? - rmgalles - 31-01-2006
The example only shows relational operators { < >= }.
What about other operators?
#define OPTION_ONE 0x01
#define OPTION_TWO 0x02
#define MY_OPTIONS (OPTION_ONE)
- or -
#define MY_OPTIONS (OPTION_TWO)
- or -
#define MY_OPTIONS (0x00)
- or -
#define MY_OPTIONS (OPTION_ONE | OPTION_TWO)
if ((MY_OPTIONS & OPTION_ONE) != 0) /* deviation from 13.7? */
{
...
}
In this case, equality operators { == != } are less likely to \"accidentally\" be always true/false (vs. intentionally always true/false), while relational operators can sometimes catch the programmer of guard (due to limited ranges of smaller integer types: [-128 to +127], [0 to +255], etc.
What about sub-expressions?
if ((u8
- misra-c - 22-08-2006
MISRA-C meeting 22-8-2006
1/ Using macros to \"configure\" features will require a deviation unless you use #if.
2/ Defensive programming is strongly encouraged. This may cause \"invarient\" conditional expressions. Deviations are required.
In this case the resulting deviation shows that the \"invariant\" has been considered, and is not a programming mistake.