Posts: 5
Threads: 2
Joined: Jul 2007
Reputation:
0
I believe that a macro has no linkage and is not an object and therefore is not covered by rule 8.9 (or indeed rule 8.4)
My problem is that C allows for multiple definitions of the same macro provided that the definitions are identical:
#define BILL some text
.
.
.
#define BILL some text
As far as I can tell, the above is legal C code and appears to not violate any MISRA rule. This is obviously undesirable!
Is my understanding correct or is there a MISRA rule to forbid such code?
Thanks,
Bill Forbes.
Posts: 70
Threads: 8
Joined: Dec 2007
Reputation:
0
ISO C states that
\"An identifier currently defined as an object-like macro shall not be redefined by another #define preprocessing directive unless the second definition is an object-like macro definition and the two replacement lists are identical. Likewise, an identifier currently defined as a function-like macro shall not be redefined by another #define preprocessing directive unless the second definition is a function-like macro definition that has the same number and spelling of parameters, and the two replacement lists are identical.\"
So your example is indeed legal ISO C, while this is not:
#define BILL some text
#define BILL some other text
Only if they are identical are they allowed by ISO C. And if they are identical, they are also harmless, so I see no point in a MISRA rule forbidding that.
Posts: 5
Threads: 2
Joined: Jul 2007
Reputation:
0
I know it's legal. MISRA rules forbid many legal C constructs for good reasons.
The problem occurs when the same macro is defined in 2 header files for example.
This poses a maintenance headache which can lead to future errors and thus I think should not be allowed.
This (I think) is the rationale behind rule 8.9. The problem is that that a macro has no linkage and is thus not covered by rule 8.9!
<t></t>
Posts: 70
Threads: 8
Joined: Dec 2007
Reputation:
0
My point is: this can never be a safety issue. Either they are different and then the linker will give you a slap on the fingers, or they are equal and then perfectly safe.
So why would there be a need for a rule?
<t></t>
Posts: 5
Threads: 2
Joined: Jul 2007
Reputation:
0
Hi,
Suppose we have 2 c source code files (cfile1.c and cfile2.c) and 2 header files (hfile1.h and hfile2.h).
In hfile1.h I can #define BILL to be something and then #include hfile1.h in cfile1.c.
Now in hfile2.h I can #define BILL to be something else and #include hfile2.c in cfile2.c.
All this will compile and link without warnings.
The fact is I have 2 macros with the same name but with different definitions.
This is unwise and I can't see a MISRA rule that would forbid such code.
Am I mistaken?
Cheers,
BILL.
Posts: 632
Threads: 18
Joined: Jan 2006
Reputation:
1
Since macros are processed during the preprocessing phase they have no linkage and are therefore not covered by rule 8.9. However, rule 5.7 states that "No identifier name should be reused" and this rule applies to all files used across a system. Macro names are identifiers and are covered by this rule.
It is a moot point whether an identical redefinition of a macro counts as a reuse or not. Within a single translation unit there is no issue with an identical redefinition. Across multiple units, the programmer's expectation is for all expansions of a given macro to behave in the same way, so again identical redefinition is not an issue. In either case, when the redefinition is not identical rule 5.7 will catch the unwanted behaviour.
Posted by and on behalf of the MISRA C Working Group
