Page History

An unsafe function-like macro is one that, when expanded, evaluates its argument more than once or does not evaluate it at all. Contrasted with function calls, which always evaluate each of their arguments exactly once, unsafe function-like macros often have unexpected and surprising effects and lead to subtle, hard-to-find defects . (See see PRE31-C. Avoid side - effects in arguments to unsafe macros). ) Consequently, every function-like macro should evaluate each of its arguments exactly once. Alternatively and preferably, defining function-like macros should be avoided in favor of inline functions . (See see PRE00-C. Prefer inline or static functions to function-like macros).)

...

The most severe problem with unsafe function-like macros is side effects of macro arguments, as shown in this noncompliant code example.:

#define ABS(x) (((x) < 0) ? -(x) : (x))

void f(int n) {
  int m;
  m = ABS(++n); /* undefined behavior */
  /* ... */
}

The invocation of the ABS() macro in this noncompliant code example expands to the following code. Since the resulting expression modifies an object more than once, its behavior is undefined. (See EXP30-C. Do not depend on order of evaluation between sequence points.)The resulting code has well-defined behavior but causes n to be incremented twice rather than once, which may be surprising to those unfamiliar with the implementation of the macro or unaware that they are using a macro in the first place.

m = (((++n) < 0) ? -(++n) : (++n));  /* undefined behavior */

...

A possible and preferable compliant solution is to define an inline function with equivalent but safe unsurprising semantics:

inline int Abs(int x) {
  return x < 0 ? -x : x;
}

...

Some implementations provide language extensions that make it possible to define safe function-like macros, such as the macro ABS(), that would otherwise require evaluating their arguments more than once. For example, the GCC extension Statements and Declarations in Expressions makes it possible to implement the macro ABS() in a safe way. Note, however, that since because relying on implementation-defined extensions introduces undesirable platform dependencies that may make the resulting code nonportable, such solutions should be avoided in favor of portable ones wherever possible . (See see MSC14-C. Do not introduce unnecessary platform dependencies).

Another GCC extension known as statement expression makes it possible for the block statement to appear where an expression is expected. The statement expression extension establishes a scope (note the curly braces) and any declarations in it are distinct from those in enclosing scopes.

#define ABS(x) __extension__ ({int  __typeof (x) __tmp = (x); __tmp < 0 ? - __tmp : __tmp; })

Risk Assessment

Defining an unsafe macro leads to invocations of the macro with an argument that has side effects, causing those side effects to occur more than once. This can lead to unexpected Unexpected or undefined program behavior can result.

Automated Detection

...

Tool	Version	Checker	Description
Astrée	Include Page Astrée_V Astrée_V	macro-parameter-multiplied macro-parameter-unused	Partially checked
Axivion Bauhaus Suite	Include Page Axivion Bauhaus Suite_V Axivion Bauhaus Suite_V	CertC-PRE12
ECLAIR	Include Page ECLAIR_V ECLAIR_V	CC2.PRE12	Fully implemented
Helix QAC	Include Page Helix QAC_V Helix QAC_V	C3456
LDRA tool suite	Include Page LDRA_V LDRA_V	562 S, 572 S, 35 D, 1 Q	Partially implemented
RuleChecker	Include Page RuleChecker_V RuleChecker_V	macro-parameter-multiplied macro-parameter-unused	Partially checked

Related Vulnerabilities

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

Related Guidelines

Bibliography

...

...

Image Modified Image Modified Image Modified