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 parethesize the macro expansion.parenthesize the 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

...