Macro replacement lists 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 replacement list.

#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

With its replacement list parenthesized, the CUBE() macro expands correctly for this type of invocation.

#define CUBE(X) ((X) * (X) * (X))
int i = 3;
int a = 81 / CUBE(i);

Non-Compliant Code Example

In this non-compliant coding example, EOF is defined as -1. The macro replacement list consists of a unary negation operator '-' followed by an integer literal '1'.

#define EOF -1
/* ... */
if (getchar() EOF) {
   /* ... */
}

In this example, the programmer has mistakenly omitted the comparison operator (see MSC02-A. Avoid errors of omission) from the conditional statement, which should be getchar() != EOF. After macro expansion, the conditional expression is incorrectly evaluated as a binary operation: getchar()-1. This is syntactically correct, even though it is certainly not what the programmer intended.

Parenthesizing the -1 in the declaration of EOF ensures that the macro expansion is evaluated correctly.

#define EOF (-1)

Once this modification is made, the non-compliant code example no longer compiles because the macro expansion results in the conditional expression getchar() (-1), which is no longer syntactically valid.

Compliant Solution

The following compliant solution uses parentheses around the macro replacement list and adds the (previously omitted) comparison operator.

#define EOF (-1)
/* ... */
if (getchar() != EOF) {
   /* ... */
}

Note that there must be a space after EOF because otherwise it becomes a function-like macro (and one that is incorrectly formed, since -1 cannot be a formal parameter).

Exceptions

PRE02-EX1. A macro that expands to a single identifier or function call is not affected by the precedence of any operators in the surrounding expression, so its replacement list need not be parenthesized.

#define MY_PID getpid()

 Risk Assessment

Failing to parenthesize macro replacement lists can cause unexpected results.

Search for vulnerabilities resulting from the violation of this rule on the CERT website.

Automated Detection

The LDRA tool suite V 7.6.0 is able to detect violations of this recommendation.

References

\[[ISO/IEC 9899-1999|AA. C References#ISO/IEC 9899-1999]\] Section 6.10, "Preprocessing directives," and Section 5.1.1, "Translation environment"
\[[Plum 85|AA. C References#Plum 85]\] Rule 1-1
\[[Summit 05|AA. C References#Summit 05]\] Question 10.1

PRE01-A. Use parentheses within macros around parameter names      01. Preprocessor (PRE)       PRE03-A. Prefer typedefs to defines for encoding types