It is necessary to understand how macro replacement works in C, particularly in the context of concatenating tokens using the ##
operator and converting macro parameters to strings using the #
operator.
Concatenating Tokens
The ##
preprocessing operator is used to merge two tokens into one while expanding macros. This is called token pasting or token concatenation. When a macro is expanded, the two tokens on either side of each ## operator are combined into a single token, which replaces the ##
and the two original tokens in the macro expansion [FSF 2005].
Token pasting is most useful when one or both of the tokens come from a macro argument. If either of the tokens next to an ##
is a parameter name, it is replaced by its actual argument before ##
executes. The actual argument is not macro expanded first.
Stringification
Parameters are not replaced inside string constants, but you can use the #
preprocessing operator instead. When a macro parameter is used with a leading #
, the preprocessor replaces it with the literal text of the actual argument, converted to a string constant [FSF 2005].
Noncompliant Code Example
The following definition for static_assert()
from DCL03-C. Use a static assertion to test the value of a constant expression uses the JOIN()
macro to concatenate the token assertion_failed_at_line_
with the value of __LINE__
.
#define static_assert(e) \ typedef char JOIN(assertion_failed_at_line_, __LINE__) \ [(e) ? 1 : -1]
__LINE__
is a predefined macro names which expands to an integer constant representing the presumed line number of the current source line within the current source file [ISO/IEC 9899:2011].
If the intention is to expand the __LINE__
macro, which is likely the case here, the following definition for JOIN()
is noncompliant:
#define JOIN(x, y) x ## y
Because the __LINE__
is not expanded, and the character array is subsequently named assertion_failed_at_line___LINE__
.
Compliant Solution
To get the macro to expand, a second level of indirection is required, as shown by this compliant solution:
#define JOIN(x, y) JOIN_AGAIN(x, y) #define JOIN_AGAIN(x, y) x ## y
JOIN(x, y)
calls JOIN_AGAIN(x, y)
so that, if x
or y
is a macro, it is expanded before the ##
operator pastes them together.
Note also that macro parameters cannot be individually parenthesized when concatenating tokens using the ##
operator, converting macro parameters to strings using the #
operator, or concatenating adjacent string literals. This is an exception, PRE01-EX2, to PRE01-C. Use parentheses within macros around parameter names.
Noncompliant Code Example
This example is noncompliant if the programmer's intent is to expand the macro before stringification:
#define str(s) #s #define foo 4 str(foo)
The macro invocation str(foo)
expands to foo
.
Compliant Solution
To stringify the result of expansion of a macro argument, you must use two levels of macros:
#define xstr(s) str(s) #define str(s) #s #define foo 4
The macro invocation xstr(foo)
expands to 4
. This is because s
is stringified when it is used in str()
, so it is not macro expanded first. However, s
is an ordinary argument to xstr()
, so it is completely macro expanded before xstr()
is expanded. Consequently, by the time str()
gets to its argument, it has already been macro expanded.
Risk Assessment
Recommendation | Severity | Likelihood | Remediation Cost | Priority | Level |
---|---|---|---|---|---|
PRE05-C | low | unlikely | medium | P2 | L3 |
Automated Detection
Tool | Version | Checker | Description |
---|---|---|---|
9.7.1 | 125 S | Fully implemented |
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
Related Guidelines
CERT C++ Secure Coding Standard: PRE05-CPP. Understand macro replacement when concatenating tokens or performing stringification
ISO/IEC 9899:2011 Section 6.10.3, "Macro replacement," Section 6.10.3.2, "The #
operator," Section 6.10.3.3, "The ##
operator," Section 6.10.3.4, "Rescanning and further replacement," and Section 6.10.8, "Predefined macro names"
Bibliography
[FSF 2005] Section 3.4, "Stringification" and Section 3.5, "Concatenation"
[Saks 2008]