Rule 19.4, does order of #definition matter?

6.19 Preprocessing Directives

Moderators: misra-c, david ward

Locked
gs
Posts: 87
Joined: Thu Nov 18, 2004 1:39 am

Rule 19.4, does order of #definition matter?

Post by gs » Fri Nov 11, 2005 7:23 pm

The MISRA II documentation states the following is compliant with the requirements of rule 19.4:

#define A 8
#define B A

However, it does not specifiy whether the following is also compliant:

#define B A
#define A 8

In the latter case, B does ultimately expand to 8, a constant, adhering to rule 19.4. However, at the time of #definition, B does not expand to a constant, braced initializer, parenthesized expression, type qualifier, storage class specifier or do-while-zero construct. Only after processing the #definition for A, is compliance certain (future re-#definition notwithstanding). My question: at what code processing point, does MISRA II, Rul 19.4, require the macro to evaluate to the prescribed formats? At the end of all preprocessing? At #definition time? Sometime else?

Gavin McCall
Posts: 72
Joined: Mon Sep 13, 2004 9:24 am

Post by Gavin McCall » Thu Jan 05, 2006 4:44 pm

ANSWER: MISRA-C Steering Team 5/1/06

The order of macro definitions is not significant, so long as all macros are defined before invocation.

This rule applies to the definition of a macro, and not its invocation.

#define B A

The above is not a permitted form of macro definition under this rule because A is not a constant, braced initializer, parenthesized expression, type qualifier, storage class specifier or do-while-zero construct

#define B (A)

The above is permitted. The replacement list is a parenthesised expression.
Gavin McCall
Personal view only.

Locked

Return to “6.19 Preprocessing Directives”