 
                            ...
One problem with unsafe macros is side effects on macro arguments, as shown by this noncompliant code example.:
| Code Block | ||||
|---|---|---|---|---|
| 
 | ||||
| #define ABS(x) (((x) < 0) ? -(x) : (x)) /* ... */ m = ABS(++n); | 
...
The resulting code is well - defined , but causes n to be incremented twice rather than once.
...
GCC's Statement Expressions along with the __typeof extension make it possible to declare and assign the value of the macro operand to a temporary of the same type and perform the computation on the temporary, thus guaranteeing that the operand will be evaluated exactly once. :
| Code Block | ||||
|---|---|---|---|---|
| 
 | ||||
| #define ABS(x)   ({ __typeof (x) __tmp = x; __tmp < 0 ? -__tmp : __tmp; })
 | 
It should be noted Note that relying on such extensions makes code non-portable nonportable and goes against guideline MSC14-C. Do not introduce unnecessary platform dependencies.
This code comes very close to violating DCL37-C. Do not declare or define a reserved identifier. It technically complies with this rule because it falls under exception DCL37-EX0EX1. However, this code is potentially unsafe if it were invoked with a variable named __tmp. Such calling code would constitute a geniuine genuine violation of DCL37-C. Finally, this code is unsafe if it is ever invoked on a platform where __tmp actually has special meaning ...(see rule DCL37-C for more infoinformation). These are considered acceptable problems, as C provides no mechanism to declare a variable in a scope that is guaranteed to be distinct from all other variables in the same scope.
...
PRE31-EX1: An exception can be made for invoking an unsafe macro with a function call argument provided that the function has no side effects. However, it is easy to forget about obscure side effects that a function might have, especially library functions for which source code is not available; even changing errno is a side effect. Unless the function is user-written and does nothing but perform a computation and return its result without calling any other functions, it is likely that many developers will forget about some side effect. Consequently, while although this exception is allowed, it is not recommended.
...
Invoking an unsafe macro with an argument that has side effects may cause those side effects to occur more than once. This practice can lead to unexpected program behavior.
...
| Tool | Version | Checker | Description | ||||||
|---|---|---|---|---|---|---|---|---|---|
| ECLAIR | 
 | macrcall | Fully implemented. | ||||||
| 
 | 9 S | Partially implemented. | |||||||
| PRQA QA-C | 
 | 3454 | Fully implemented. | 
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
...
| CERT C Secure Coding Standard | PRE12-C. Do not define unsafe macros | 
| CERT C++ Secure Coding Standard | PRE31-CPP. Avoid side-effects in arguments to unsafe macros | 
| ISO/IEC TR 24772:2013 | Pre-processor Directives [NMP] | 
| MISRA - C:2012 | Rule 19.620.5 (advisory) | 
Bibliography
| [Plum 1985] | Rule 1-11 | 
...