SEI CERT C Coding Standard

Space shortcuts

Page tree

The arguments to a macro must not include preprocessor directives, such as #define, #ifdef, and #include. Doing so results in undefined behavior, according to the C Standard, 6.10.5, paragraph 11 [ISO/IEC 9899:2024]:

The sequence of preprocessing tokens bounded by the outside-most matching parentheses forms the list of arguments for the function-like macro. The individual arguments within the list are separated by comma preprocessing tokens, but comma preprocessing tokens between matching inner parentheses do not separate arguments. If there are sequences of preprocessing tokens within the list of arguments that would otherwise act as preprocessing directives, the behavior is undefined.

See also undefined behavior 93.

This rule also applies to the use of preprocessor directives in arguments to any function where it is unknown whether or not the function is implemented using a macro. This includes all standard library functions, such as memcpy(), printf(), and assert(), because any standard library function may be implemented as a macro. (C24, 7.1.4, paragraph 1).

Noncompliant Code Example

In this noncompliant code example [GCC Bugs], the programmer uses preprocessor directives to specify platform-specific arguments to memcpy(). However, if memcpy() is implemented using a macro, the code results in undefined behavior.

#include <string.h>
 
void func(const char *src) {
  /* Validate the source string; calculate size */
  char *dest;
  /* malloc() destination string */ 
  memcpy(dest, src,
    #ifdef PLATFORM1
      12
    #else
      24
    #endif
  );
  /* ... */
}

Compliant Solution

In this compliant solution [GCC Bugs], the appropriate call to memcpy() is determined outside the function call:

#include <string.h>

void func(const char *src) {
  /* Validate the source string; calculate size */
  char *dest;
  /* malloc() destination string */ 
  #ifdef PLATFORM1
    memcpy(dest, src, 12);
  #else
    memcpy(dest, src, 24);
  #endif
  /* ... */
}

Risk Assessment

Including preprocessor directives in macro arguments is undefined behavior.

Rule

Severity

Likelihood

Remediation Cost

Priority

Level

PRE32-C

Low

Unlikely

Medium

P2

L3

Automated Detection

Tool

Version

Checker

Description

Astrée
24.04
macro-argument-hashFully checked
Axivion Bauhaus Suite

7.2.0

CertC-PRE32Fully implemented
CodeSonar
8.1p0
LANG.PREPROC.MACROARGPreprocessing directives in macro argument

ECLAIR

1.2

CC2.PRE32

Fully implemented

Helix QAC

2024.3

C0853

C++1072

Fully implemented
Klocwork

2024.3

MISRA.EXPANSION.DIRECTIVEFully implemented
LDRA tool suite
9.7.1
341 SFully implemented
Parasoft C/C++test

2023.1

CERT_C-PRE32-a
Arguments to a function-like macro shall not contain tokens that look like preprocessing directives
PC-lint Plus

1.4

436, 9501

Fully supported

Polyspace Bug Finder

R2024a

CERT C: Rule PRE32-CChecks for preprocessor directive in macro argument (rule fully covered)
RuleChecker
24.04
macro-argument-hashFully checked

Related Vulnerabilities

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

Bibliography

[GCC Bugs]"Non-bugs"
[ISO/IEC 9899:2024]6.10.5, "Macro Replacement"


4 Comments

  1. Aaron Ballman

    For example, standard library functions, such as memcpy(), printf(), and assert(), may be implemented as macros.

    I think this is not stated strongly enough. Strictly speaking, ALL C library functions can be implemented as a function-like macro in addition to a real function definition, so for maximal portability you would need to not use a preprocessor directive in the invocation of any C Standard Library function. See C17 7.1.4p1.

    1. David Svoboda

      Aaron:

      This has far-reaching implications, and I don't see much in the way of guarantees if every standard library function could be implemented as a function-like macro, as is suggested in C11,s7.1.4:

      Any function declared in a header may be additionally implemented as a function-like macro defined in the header, so if a library function is declared explicitly when its header is included, one of the techniques shown below can be used to ensure the declaration is not affected by such a macro.

      For example, is there any guarantee these macros evaluate their arguments exactly once? If not, then you could not nest standard library function calls, such as printf("%d", atoi(string)).

      I know our research depends on the ability to nest #ifdefs within arguments to a function call, and I've seen it in lots of source code...if the functions could be macros instead, that would be a Big Mess(tm).



      1. Aaron Ballman

        Yeah, I was recently questioning the utility of this rule because of this. What's more sad is that the best solution I thought of to portably deal with this... isn't allowed in conforming C:

        _Static_assert(!defined(memcpy), "memcpy implemented as a macro");

        Because `defined` cannot be used outside of a preprocessor conditional inclusion directive. You basically have to write:

        #ifdef memcpy
_Static_assert(false, "memcpy implemented as a macro");
#endif

        For example, is there any guarantee these macros evaluate their arguments exactly once? 

        There is such a guarantee in 7.1.4p1: "Any invocation of a library function that is implemented as a macro shall expand to code that evaluates each of its arguments exactly once, fully protected by parentheses where necessary, so it is generally safe to use arbitrary expressions as arguments." though there is a footnote attached to it that says such macros might not contain the same sequence points as a function call, however (which seems like a separate issue not explicitly discussed in any of the rules).

        1. David Svoboda

          I've reworded the rule's intro to clarify that any standard C library function must not have preprocessor directives in its arguments.