+- 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.19 Preprocessing Directives (https://forum.misra.org.uk/forumdisplay.php?fid=43)
+---- Thread: Rule 19.4, does order of #definition matter? (/showthread.php?tid=88)
Rule 19.4, does order of #definition matter? - gs - 11-11-2005
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 - 05-01-2006
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.