+- MISRA Discussion Forums (https://forum.misra.org.uk)
+-- Forum: MISRA C (https://forum.misra.org.uk/forumdisplay.php?fid=4)
+--- Forum: MISRA C:2012 and MISRA C:2023 guidelines (https://forum.misra.org.uk/forumdisplay.php?fid=21)
+---- Forum: 8.20 Preprocessing directives (https://forum.misra.org.uk/forumdisplay.php?fid=175)
+---- Thread: 20.12 Does the stringification really matter? (/showthread.php?tid=1778)
20.12 Does the stringification really matter? - Loïc - 07-07-2026
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?
RE: 20.12 Does the stringification really matter? - misra-c - 08-10-2026
The MISRA C WG will consider this [ID: 482 applies]