Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Wiki MarkupThe macro expansion must always be parenthesized to protect any Macro replacement lists should be parenthesized to protect any lower-precedence operators from the surrounding expression. See also \[[PRE01|PRE01-A. Use parentheses within macros around variable names]\].

...

also PRE00-C. Prefer inline or static functions to function-like macros and PRE01-C. Use parentheses within macros around parameter names.

Noncompliant Code Example

This CUBE() macro definition is non-compliant noncompliant because it fails to parenthesize the macro expansion.replacement list:

Excerpt
hiddentrue

compliant=no,enclose=yes,compile=yes

Code Block
bgColor#FFcccc
langc
Code Block

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

As a result, the invocation

Code Block
bgColor#FFcccc
langc

int a = 81 / CUBE(i);

expands to

Excerpt
hiddentrue

compliant=no,enclose=yes,compile=no

Code Block
bgColor#FFcccc
langc

int a = 81 / i * i * i;

which evaluates as

Code Block
bgColor#FFcccc
langc

int a = ((81 / i) * i) * i);  /* evaluatesEvaluates to 243 */

while which is not the desired behavior is

Code Block

int a = 81 / ( i * i * i); /* evaluates to 3 */

Compliant Solution

.

Compliant Solution

With its replacement list parenthesizedBy parenthesizing the macro expansion, the CUBE() macro expands correctly (when invoked in this manner)for this type of invocation.

Code Block
bgColor#ccccff
langc

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

However, if a parameter appears several times in the expansion, the macro may not work properly if the actual argument is an expression with side effects. Given the CUBE() macro above, the invocation

Code Block

int a = 81 / CUBE(i++);

expands to

Code Block

int a = 81 / (i++ * i++ * i++);

Wiki Markup
which is undefined (see \[[EXP30|EXP30-C. Do not depend on order of evaluation between sequence points]\]).

Priority: P3 Level: L3

Component

Value

Severity

1 (low)

Likelihood

1 (unlikely)

Remediation cost

3 (low)

References

...

This compliant solution violates PRE00-C. Prefer inline or static functions to function-like macros. Consequently, this solution would be better implemented as an inline function.

Noncompliant Code Example

In this noncompliant code example, END_OF_FILE is defined as -1. The macro replacement list consists of a unary negation operator followed by an integer literal 1:

Code Block
bgColor#FFcccc
langc
#define END_OF_FILE -1
/* ... */
if (getchar() END_OF_FILE) {
   /* ... */
}

In this example, the programmer has mistakenly omitted the comparison operator from the conditional statement, which should be getchar() != END_OF_FILE. (See void MSC02-C. Avoid errors of omission.) After macro expansion, the conditional expression is incorrectly evaluated as a binary operation: getchar()-1. This statement is syntactically correct, even though it is certainly not what the programmer intended. Note that this example also violates DCL00-C. Const-qualify immutable objects.

Parenthesizing the -1 in the declaration of END_OF_FILE ensures that the macro expansion is evaluated correctly:

Code Block
#define END_OF_FILE (-1)

Once this modification is made, the noncompliant code example no longer compiles because the macro expansion results in the conditional expression getchar() (-1), which is no longer syntactically valid. Note that there must be a space after END_OF_FILE because, otherwise, it becomes a function-like macro (and one that is incorrectly formed because −1 cannot be a formal parameter).

Compliant Solution

In this compliant solution, the macro definition is replaced with an enumeration constant in compliance with DCL00-C. Const-qualify immutable objects. In addition, because EOF is a reserved macro defined in the <stdio.h> header, the compliant solution must also use a different indentifier in order to comply with DCL37-C. Do not declare or define a reserved identifier.

Code Block
bgColor#ccccff
langc
enum { END_OF_FILE = -1 };
/* ... */
if (getchar() != END_OF_FILE) {
   /* ... */
}

Exceptions

PRE02-C-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.

Code Block
#define MY_PID getpid()

PRE02-C-EX2: A macro that expands to an array reference using the array-subscript operator [], or an expression designating a member of a structure or union object using either the member-access . or -> operators is not affected by the precedence of any operators in the surrounding expression, so its replacement list need not be parenthesized.

Code Block
#define NEXT_FREE block->next_free
#define CID customer_record.account.cid
#define TOOFAR array[MAX_ARRAY_SIZE]

Risk Assessment

Failing to parenthesize macro replacement lists can cause unexpected results.

Recommendation

Severity

Likelihood

Remediation Cost

Priority

Level

PRE02-C

Medium

Probable

Low

P12

L1

Automated Detection

ToolVersionCheckerDescription
Axivion Bauhaus Suite

Include Page
Axivion Bauhaus Suite_V
Axivion Bauhaus Suite_V

CertC-PRE02
CodeSonar
Include Page
CodeSonar_V
CodeSonar_V

LANG.PREPROC.MACROEND

LANG.PREPROC.MACROSTART

Macro Does Not End With ) or }

Macro Does Not Start With ( or {

ECLAIR

Include Page
ECLAIR_V
ECLAIR_V

CC2.PRE02

Fully implemented
Helix QAC

Include Page
Helix QAC_V
Helix QAC_V

C3409
Klocwork
Include Page
Klocwork_V
Klocwork_V
MISRA.DEFINE.BADEXP
LDRA tool suite
Include Page
LDRA_V
LDRA_V

77 S

Fully implemented

Parasoft C/C++test
Include Page
Parasoft_V
Parasoft_V
CERT_C-PRE02-a

Enclose in parentheses whole definition of a function-like macro

PC-lint Plus

Include Page
PC-lint Plus_V
PC-lint Plus_V

773, 973

Fully supported

Related Vulnerabilities

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

Related Guidelines

SEI CERT C++ Coding StandardVOID PRE02-CPP. Macro replacement lists should be parenthesized
ISO/IEC TR 24772:2013Operator Precedence/Order of Evaluation [JCW]
Pre-processor Directives [NMP]

Bibliography

[Plum 1985]Rule 1-1
[Summit 2005]Question 10.1


...

Image Added Image Added Image Added

...