How to quickly see interesting warnings generated by the PVS-Studio analyzer for C and C ++ code?

From time to time, programmers who begin to get acquainted with the PVS-Studio code analyzer ask: “Is there a list of warnings that accurately indicate errors?” There is no such list for the reason that uninteresting (false) warnings in one project appear in another very important and helpful. However, to begin acquaintance with the analyzer with the most interesting warnings is quite possible. Let's take a closer look at this topic.

The trouble is that during the first starts, the programmer receives, as a rule, a huge number of warnings in which he “drowns”. Naturally, he has a desire to get acquainted with the most interesting warnings in order to understand whether he should spend all this time at all. Great, here are three simple steps that will allow you to get acquainted with the most interesting positives.

Step 1

Disable all types of alerts except general (GA). A common mistake: enable all kinds of warnings. For inexperienced users it seems that the more you turn it on, the better. This is not true! There are sets of diagnostics, such as 64-bit checks and MISRA rules, which should be used only with a clear idea of ​​what it is and how to work with them. For example, turning on MISRA diagnostics for an ordinary application program, you will drown in tens, thousands, or hundreds of thousands of messages like:

• V2506 . Misra. A function should have a single point of exit at the end.
• V2507 . Misra. The body of a loop \ conditional statement should be enclosed in braces.
• V2523 . Misra. All integer constants of unsigned type should have 'u' or 'U' suffix.

Most MISRA warnings do not indicate errors, but code smells. Naturally, a person begins to ask questions. How to find something interesting in the mass of all these warnings? Diagnostics under what numbers should he look? These are the wrong questions. You just need to disable the MISRA kit. This is the standard for writing quality code for embedded devices. The essence of the standard: to make the code extremely simple and understandable. Do not try to apply it where it is inappropriate.

Note. Yes, there are rules in the MISRA standard aimed at detecting real errors. Example: V2538- The value of uninitialized variable should not be used. But don't be afraid to disable the MISRA standard. You will not lose anything. True errors will still be found in general purpose diagnostics (GA). For example, an uninitialized variable will be found thanks to the V614 diagnostic .

Step 2

Any static analyzer generates false positives during the first starts and requires a certain configuration. Nothing can be done with this, but it is not as scary as it might seem. Even a simple quick setup allows you to remove most of the false warnings and begin to get acquainted with an already quite adequate report. We won’t talk about this in more detail, since I wrote about it many times, for example, in this article: " Characteristics of the PVS-Studio analyzer using the EFL Core Libraries example, 10-15% of false positives ."

Spend a little time disabling explicitly irrelevant alerts and dealing with false positives due to macros. Macros are generally the main source of false positives, since a warning appears wherever a failed macro is used. To suppress warnings in macros, a special kind of comments can be placed next to their declaration. The format for writing comments is discussed in more detail in the documentation .

Yes, the initial setup will take a little time, but dramatically improve the perception of the report by eliminating distracting noise. Take some time for this. If there are any difficulties or questions, we are always ready to help and suggest how best to configure the analyzer. Feel free to write and ask us questions.

Step 3

Start learning warnings from level 1. And only then look at 2 and 3. Warning levels are nothing more than the reliability of the warning. Level 1 warnings are more likely to indicate a real mistake than 2.

You can say that when you select “watch level 1”, you click the “watch the most interesting errors” button.

The classification of PVS-Studio alerts by levels is described in more detail in the article “ How and why static analyzers fight against false positives ”.

So why is there still no list?

However, an idea with a list of the most useful warnings may seem reasonable anyway. Let me show with a practical example that the usefulness of diagnostics is relative and depends on the project.

Consider warning V550 . A warning reveals a potential error due to the fact that the operator == or! = Is used to compare floating-point numbers.

Most of the developers with whom I spoke believe that this diagnosis is of little use and turn it off, since all the positives for their project are false. And that is why this diagnosis has low reliability and is located at the 3rd level.

Indeed, in most applications, the float / double types are used in very simple algorithms. And often a comparison with a constant is used solely to check if a default value is set, or if it has changed. In this case, an accurate check is quite appropriate. I will explain this with a pseudo-code.

float value = 1.0f;
if (IsUserInputNewValue())
  value = GetUserValue();
if (value == 1.0f)
  DefaultBehavior();
else
  Foo(value);

Here the comparison (value == 1.0f) is correct and safe.

Does this mean that the V550 is an uninteresting diagnosis? Not. It all depends on the project. I will quote a fragment from the article " How we tested static analysis on our project of a training simulator of endovascular surgery, " written by one of our users.

So, what does the static analyzer draw our attention to:

V550 An odd precise comparison: t! = 0. It's probably better to use a comparison with defined precision: fabs (A - B)> Epsilon. objectextractpart.cpp 3401

D3DXVECTOR3 N = VectorMultiplication(
                  VectorMultiplication(V-VP, VN), VN);
float t = Qsqrt(Scalar(N, N));
if (t!=0)
{
  N/=t;
  V = V - N * DistPointToSurface(V, VP, N);
}

Similar errors are repeated quite often in this library. I will not say that this came as a surprise to me. Already previously I encountered incorrect work with floating-point numbers in this project. However, there were no resources to systematically check the source for this. According to the results of the verification, it became clear that you need to give the developer something to read to broaden his horizons in terms of working with floating-point numbers. I threw him links to a couple of good articles. Let's look at the result. It is difficult to say unambiguously whether this error causes real malfunctions in the program. The current solution sets a number of requirements for the initial polygonal network of arteries, along which the spreading of a radiopaque substance is simulated. If the requirements are not met, then the program may crash, or obviously incorrect operation. Some of these requirements are obtained analytically, and part - empirically. It is possible that this second part of the requirements grows just from incorrect work with floating-point numbers. It should be noted that not all found cases of using exact comparison of floating-point numbers were an error.

As you can see, what is not interesting in some projects is of interest in others. This makes it impossible to create a list of "most interesting."

Note. It is possible to set the warning level using the settings. For example, if you think that V550 diagnostics deserve close attention, you can move it from the third level to the first. This type of settings is described in the documentation (see "How to set your level for specific diagnostics").

Conclusion

Now you know how to start studying the analyzer warnings, considering the most interesting of them. And do not forget to look in the documentation to get acquainted with the detailed description of warnings. Sometimes it happens that behind a nondescript, at first glance, warning is hell. An example of such diagnostics: V597 , V1026 . Thanks for attention.

If you want to share this article with an English-speaking audience, then please use the link to the translation: Andrey Karpov. How to quickly check out interesting warnings given by the PVS-Studio analyzer for C and C ++ code?