Skip to end of metadata
Go to start of metadata

Parenthesize all parameter names in macro definitions. See also PRE00-C. Prefer inline or static functions to function-like macros and PRE02-C. Macro replacement lists should be parenthesized.

Noncompliant Code Example

This CUBE() macro definition is noncompliant because it fails to parenthesize the parameter names:

#define CUBE(I) (I * I * I)

As a result, the invocation

int a = 81 / CUBE(2 + 1);

expands to

int a = 81 / (2 + 1 * 2 + 1 * 2 + 1);  /* Evaluates to 11 */

which is clearly not the desired result.

Compliant Solution

Parenthesizing all parameter names in the CUBE() macro allows it to expand correctly (when invoked in this manner):

#define CUBE(I) ( (I) * (I) * (I) )
int a = 81 / CUBE(2 + 1);

Exceptions

PRE01-C-EX1: When the parameter names are surrounded by commas in the replacement text, regardless of how complicated the actual arguments are, there is no need for parenthesizing the macro parameters. Because commas have lower precedence than any other operator, there is no chance of the actual arguments being parsed in a surprising way. Comma separators, which separate arguments in a function call, also have lower precedence than other operators, although they are technically different from comma operators.

#define FOO(a, b, c) bar(a, b, c)
/* ... */
FOO(arg1, arg2, arg3);

PRE01-C-EX2: 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. The following JOIN() macro concatenates both arguments to form a new token. The SHOW() macro converts the single argument into a string literal, which is then passed as a parameter to printf() and as a string and as a parameter to the %d specifier. For example, if SHOW() is invoked as SHOW(66);, the macro would be expanded to printf("66" " = %d\n", 66);.

#define JOIN(a, b) (a ## b)
#define SHOW(a) printf(#a " = %d\n", a)

See PRE05-C. Understand macro replacement when concatenating tokens or performing stringification for more information on using the ## operator to concatenate tokens.

Risk Assessment

Failing to parenthesize the parameter names in a macro can result in unintended program behavior.

Recommendation

Severity

Likelihood

Remediation Cost

Priority

Level

PRE01-C

Medium

Probable

Low

P12

L1

Automated Detection

ToolVersionCheckerDescription
Astrée
19.04
macro-parameter-parenthesesFully checked
Axivion Bauhaus Suite

6.9.0

CertC-PRE01Fully implemented
ECLAIR
1.2
CC2.PRE01Fully implemented
Klocwork
2018
MISRA.DEFINE.NOPARS
LDRA tool suite
9.7.1

78 S

Enhanced Enforcement

Parasoft C/C++test
10.4.2
CERT_C-PRE01-a
In the definition of a function-like macro each instance of a parameter shall be enclosed in parentheses unless it is used as the operand of # or ##
Polyspace Bug Finder

R2018a

MISRA C:2012 Rule 20.7

Expressions resulting from the expansion of macro parameters shall be enclosed in parentheses

PRQA QA-C
9.5
3410Fully implemented
PVS-Studio

6.23

V733
RuleChecker
19.04
macro-parameter-parenthesesFully checked

Related Vulnerabilities

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

Related Guidelines

SEI CERT C++ Coding StandardVOID PRE01-CPP. Use parentheses within macros around parameter names
ISO/IEC TR 24772:2013Operator Precedence/Order of Evaluation [JCW]
Pre-processor Directives [NMP]
MISRA C:2012

Rule 20.7 (required)

Bibliography

[Plum 1985]
[Summit 2005]Question 10.1



5 Comments

  1. This example:
    #define SHOW(a) printf(#a " = %d\n", a)
    gives wrong behavior for calls like SHOW(i%j). It should be replaced with
    #define SHOW(a) printf("%s = %d\n", #a, a)

  2. Silly question, why is this a rec & not a rule? It is easily enforceable by inspecting your #define statements, failure often yields unintended behavior, and you have a small list of exceptions.

    1. RCS sez:

      > so the distinction between a rule and a recommendation is a fairly gray area. the best way i can describe it is in terms of remediation of an existing system. if you can tell a software development manager that he should go back and spend $$$ to repair some problem, it is probably a rule. if you can't make this argument, it is probably a recommendation.

      in this specific case, failing to "Use parentheses within macros around parameter names" does not in itself constitute an error. the error occurs when this macro is used in a certain way. although this is not the exact same thing, pre31-C gives an example of a rule:

      PRE31-C. Never invoke an unsafe macro with arguments containing assignment, increment, decrement, volatile access, or function call

      it is very hard to write the corresponding rule here.... don't call a macro if the arguments may expand in an unintended manner.

      we could in fact reclassify this if you feel strongly. right now, the main reason not to (besides my argument above) is that moving it now would result in having to shuffle a bunch of things around.

      rCs

  3. I think the MISRA C 2012 mapping is to 20.7 (required) rather than 20.1 ?

  4. (on behalf of MISRA-C Working Group).  You are correct that Rule 20.7 is the appropriate mapping.

    One difference with the CERT rule is that the MISRA C:2012 rule does not require parenthesis within the macro definition. 

    So the following would also be compliant in MISRA

    #define CUBE(I) ( I * I * I )
    int a = 81 / CUBE( (2 + 1) );