Does 13.7 apply to ALL invariant Boolean expressions?

6.13 Control Statement Expressions

Moderators: misra-c, david ward

Posts: 7
Joined: Fri Jan 20, 2006 3:45 pm
Location: USA

Does 13.7 apply to ALL invariant Boolean expressions?

Post by rmgalles » Tue Jan 31, 2006 10:12 pm

The example only shows relational operators { < <= > >= }.

What about other operators?
#define OPTION_ONE 0x01
#define OPTION_TWO 0x02

- or -
- or -
#define MY_OPTIONS (0x00)
- or -

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_MAX /* useful to confirm values valid, and declare arrays */
} Color_T;

Color_T color;

void (* const Color_Function_Table[COLOR_MAX])(void) = {

/* make sure 'color' is valid before executing function jump table */
if (color < COLOR_MAX)
... /* 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)

Would this be a deviation of rule 13.7?

Posts: 569
Joined: Thu Jan 05, 2006 1:11 pm

Post by misra-c » Tue Aug 22, 2006 4:41 pm

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.
Posted by and on behalf of
the MISRA C Working Group


Return to “6.13 Control Statement Expressions”