07-07-2026, 09:59 AM
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:
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?
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?

