Page 1 of 1

Does 13.7 apply to ALL invariant Boolean expressions?

Posted: Tue Jan 31, 2006 10:12 pm
by rmgalles
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 <= 0xff) && ((flags & MASK) != 0)) /* compliant? */

I'd expect non-compliant, since the (u8 <= 0xff) expression is always true, even though the if expression may not always be true (based on value of 'flags').

Sometimes, the compiler/optimizer is used to generate more efficient code based on build options (using common code on several target products).

For example:
#define Some_Option() (false)
- or -
#define Some_Option() (Some_Calibration)

if (Some_Option()) { ... }


The option can be \"hard-coded\" to 'false' for an entry-model product (never enabled for this product), while it is changed to 'Some_Calibration' for an upgraded product.

This can be easier to read than using #ifdef/#endif blocks to effectively comment out code -- let the compiler optimize the code out instead.
(I realize, this technically deviates from rule 14.1 for a particular build)


Also, one of the example shows:
enum ec {RED, BLUE, GREEN} col;

if (col <= GREEN) /* Not compliant - always true */

This expression is NOT necessarily always true with respect to defensive programming. The possible values for 'col' are [0 to INT_MAX], while the only VALID (EXPECTED) values are [RED to GREEN].

If this enumerated type is used as an index to a jump table, it would be a GOOD idea to make sure that the value is VALID:

typedef enum Color_Tag {
COLOR_RED,
COLOR_BLUE,
COLOR_GREEN,
COLOR_MAX /* useful to confirm values valid, and declare arrays */
} Color_T;

Color_T color;

void (* const Color_Function_Table[COLOR_MAX])(void) = {
&Function_Red,
&Function_Blue,
&Function_Green
};

/* make sure 'color' is valid before executing function jump table */
...
if (color < COLOR_MAX)
{
Color_Function_Table[color]();
}
else
{
... /* handle invalid 'color' */
}


Would the above be a violation of rule 13.7?
What about when 'color' is a parameter to a function:

My_Color_Handler(Color_T color)
{
if (color < COLOR_MAX)
{
Color_Function_Table[color]();
}
}

Would this be a deviation of rule 13.7?

Posted: Tue Aug 22, 2006 4:41 pm
by misra-c
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.