The macro expansion should be parenthesized to protect any lower-precedence operators from the surrounding expression. See also [[PRE00-A. Prefer inline functions to macros]] and [[PRE01-A. Use parentheses within macros around parameter names]].
Non-Compliant Code Example
This CUBE()
macro definition is non-compliant because it fails to parenthesize the macro expansion.
#define CUBE(X) (X) * (X) * (X) int i = 3; int a = 81 / CUBE(i);
As a result, the invocation
int a = 81 / CUBE(i);
expands to
int a = 81 / i * i * i;
which evaluates as
int a = ((81 / i) * i) * i); /* evaluates to 243 */
which is not the desired behavior.
Compliant Solution
By parenthesizing the macro expansion, the CUBE()
macro expands correctly (when invoked in this manner).
#define CUBE(X) ((X) * (X) * (X)) int i = 3; int a = 81 / CUBE(i);
Non-Compliant Code Example
The problem is not limited to function-like macros.
#define sum a+b /* ... */ int result = sum*4;
The value of result
is a+(b*4)
instead of the expected (a+b)*4
.
Compliant Solution
Parenthesizing the macro yields the expected answer.
#define sum (a+b) /* ... */ int result = sum*4;
Note that there must be a space after sum
, otherwise it becomes a function-like macro.
Exceptions
A macro that expands to a single identifier or function call will not change the precedence of any operators in the surrounding expression, so it need not be parenthesized.
#define MY_PID getpid()
Risk Assessment
Failing to parenthesize around a function-like macro can result in unexpected arithmetic results.
Rule |
Severity |
Likelihood |
Remediation Cost |
Priority |
Level |
---|---|---|---|---|---|
PRE02-A |
1 (low) |
1 (unlikely) |
3 (low) |
P3 |
L3 |
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
References
[[Summit 05]] Question 10.1
[[ISO/IEC 9899-1999]] Section 6.10, "Preprocessing directives," and Section 5.1.1, "Translation environment"