Contents
V1003. Macro expression is dangerous or suspicious.
The analyzer has detected a possible error in a macro declaration.
Consider the following example:
#define sqr(x) x * xThis 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.0For the same reason, the arguments should also be enclosed in parentheses:
sqr(M_PI + 0.42); // M_PI + 0.42 * M_PI + 0.42Because 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 * BDepending 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();
#endifWhile 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();
#endifYou can look at examples of errors detected by the V1003 diagnostic. |
Was this page helpful?
