V1003. The macro expression is dangerous, or it is suspicious.


The analyzer has detected a possible error in a macro declaration.

Consider the following example:

#define sqr(x) x * x

This macro should be rewritten in the following way:

#define sqr(x) ((x) * (x))

The original implementation has two flaws that make the macro error-prone. First of all, the macro itself should be enclosed in parentheses; otherwise, the following code would execute incorrectly:

double d = 1.0 / sqr(M_PI);  // 1.0 / M_PI * M_PI == 1.0

For the same reason, the arguments should also be enclosed in parentheses:

sqr(M_PI + 0.42);  // M_PI + 0.42 * M_PI + 0.42

Because the preprocessor handles the code at the lexeme level, it sometimes fails to build a correct syntax tree relying on the macro's text. For example:

#define FOO(A,B) A * B

Depending on the context, this may be both a multiplication of A by B and a declaration of variable B pointing to A. Since a macro declaration provides no information about how the macro will be used, false warnings are possible. In that case, use one of the means described in the documentation to suppress such false positives.

Note. This diagnostic is similar to V733. The latter is more accurate and produces fewer false positives since it deals with an already expanded macro rather than its declaration. On the other hand, V733's diagnostic capabilities are more limited, which makes it unable to recognize many errors.

Other type of found errors can look as follows:

#if A
doA();
#else doB();
#endif

While code refactoring, line break was deleted by accident, and 'doB()' function couldn't be called. At the same time the code stayed compiled.

Fixed variant of code:

#if A
doA();
#else
doB();
#endif

Bugs Found

Checked Projects
363
Collected Errors
13 495