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.

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

References

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