MISRA Discussion Forums - 8.20 Preprocessing directives

20.12 Does the stringification really matter?

Tue, 07 Jul 2026 09:59:02 +0000

Hello,

While looking at violations of 20.12 A macro parameter used as an operand to the "#" or "##" operators, which is itself subject to further macro replacement, shall only be used as an operand to these operators, I discovered that most of them were of the form:

Code:
assert(value < LIMIT)

Indeed, the macro parameter of assert is typically stringified, and in that case it contains the macro LIMIT that is itself subject to further replacement.

However, I don't see the safety case for this violation. The fact that the unexpended version of the macro will appear in the string is exactly what is needed.

I agree that with token pasting (##), this situation could lead to hard to understand code, but not with stringification.

FWIW, I discussed this with MISRA C++ (that contains the same rule), and the sentiment of the group was that the rule should be updated to remove the stringification part.

What do you think?

MISRA C:2012 Rule 20.5 applicable for inactive code ?

Mon, 06 Jan 2020 13:43:19 +0000

Hello,

MISRA C:2012 Rule 20.5 - #undef should not be used.

For the following code snippet, #undef is seen at line 5 and 8.
As Rule 20.5 complains for use of #undef, please let us know whether code at line 8, which is inactive code due to #else is Non-compliant or not according MISRA C:2012 Rule 20.5 ?

1. #define FLAG 100
2.
3. #ifdef FLAG
4. #define L 0
5. #undef L
6. #else
7. #define X 0
8. #undef X
9. #endif

Regards
Girish.M

Rule 20.2

Thu, 08 Mar 2018 15:06:26 +0000

Why is
#include "c:\headers\measurement_regs.h "
non compliant to rule 20.2 due to \ in the path?

Rule 20.8 and #elif

Wed, 01 Nov 2017 16:03:37 +0000

It is pretty clear from the Amplification that this is not a violation of Rule 20.8:

Code:
#if 0

  #if 10  /* not evaluated, not a violation */

  #endif

#endif

and that this is:

Code:
#if 0

#elif 20  /* evaluated, violation */

#endif

but is the following intended to be a violation of this rule?:

Code:
#if 1

#elif 20  /* ??? */

#endif

It is not clear if the preprocessing directive #elif 20 is evaluated for the purpose of this rule.

Clarification on Rule 20.8

Thu, 05 Mar 2015 12:47:47 +0000

In the below case

#if 10
----
#elif 20
----
#endif

Since the part of the code
#elif 20
----
#endif

Is never gonna execute, is the rule applicable to this part of code i.e the part #elif 20 will be ignored while compilation so should the violation should be reported on it ?

Rule 20.3 space after #include

Fri, 13 Feb 2015 12:36:50 +0000

The amplification to rule 20.3 states that the rule applies "after macro replacement" has been performed. Is the number/absence of spaces and comments between #include and the " or < irrelevant?

So for example:

Code:
#include              /* no space - compliant ? */

#include/* comment*/  /* compliant  ? */.