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

From time to time, programmers who are starting to familiarize themselves 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 are in another very important and helpful. However, it is quite possible to begin acquaintance with the analyzer with the most interesting warnings. Let's look at this topic in more detail.



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

Step 1

')

Disable all alert types except Major (GA). Common mistake: enable all kinds of warnings. Inexperienced users think that the more they include the better. This is not true! There are sets of diagnostics, such as 64-bit checks and MISRA-rules, which should be used, only clearly representing what it is and how to work with them. For example, turning on MISRA diagnostics for an ordinary application program will result in tens, thousands, or hundreds of thousands of messages like:

• V2506 . MISRA. This should be a single point of exit at the end.
• V2507 . MISRA. The body of a loop \ conditional statement should not 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 starts asking questions. How to find something interesting in the mass of all these warnings? What diagnostics should he look at? 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: make the code extremely simple and straightforward. Do not try to apply it where it is inappropriate.



Note. Yes, in the MISRA standard there are rules aimed at identifying real errors. Example: V2538 - The value of uninitialized variable should not be used. But do not be afraid to disable the MISRA-standard. You will not lose anything. These errors will still be found in the framework of general-purpose diagnostics (GA). For example, an uninitialized variable will be found by diagnosing the V614 .

Step 2

Any static analyzer at the first starts produces false positives and requires a certain setting. With this nothing can be done, but it is not as scary as it may 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’re not going to talk more about this, since I’ve written many times about it, for example, in this article: " Characteristics of the PVS-Studio analyzer on the example of EFL Core Libraries, 10-15% of false positives ."



Spend a little time turning off clearly irrelevant warnings and dealing with false positives due to macros. Macros are generally the main source of false positives, since a warning appears everywhere where an unsuccessfully implemented macro is used. To suppress warnings in macros, special comments can be placed next to their declaration. Details of the format for writing comments are discussed in the documentation .



Yes, the initial setup takes a little time, but will dramatically improve the perception of the report by eliminating distracting noise. Spend some time with 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 watch 2 and 3. Alert levels are nothing more than the accuracy of a warning. Level 1 warnings are more likely to indicate a real error than 2.



You can say that choosing “watch level 1”, you press the button “watch the most interesting mistakes”.



PVS-Studio warnings classification by levels is described in more detail in the article " How and why static analyzers deal with false alarms ."

So why is there no list yet?

Nevertheless, the idea of ​​a list of the most useful warnings may still seem reasonable. Let me show you with a practical example that the diagnostic utility is relative and depends on the project.



Consider the V550 warning. The warning reveals a potential error related 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 diagnostic is of little use and disable it, since all the positives for their project are false. And that is why this diagnosis has low accuracy and is located at the 3rd level.



Indeed, in most applications float / double types are used in very simple algorithms. And often a comparison with a constant is used solely to check whether a certain value is set by default, or whether it has changed. In this case, an accurate check is quite appropriate. Let me explain this pseudocode.

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 diagnostic? Not. It all depends on the project. I will quote a fragment from the article “ About how we tried a static analysis on our project of an educational simulator of endovascular surgery, ” written by one of our users.



So, what does the static analyzer pay attention to here?



V550 An odd precise comparison: t! = 0. It is better to use a 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); } 

Such errors are repeated quite often in this library. I will not say that it came as a surprise to me. Already earlier I ran into incorrect work with floating point numbers in this project. However, there were no resources to systematically check the sources for this. As a result of the test, it became clear that you need to give the developer something to read to broaden the horizon in terms of working with floating point numbers. Threw him links to a couple of good articles. Let's look at the result. It is difficult to unequivocally say whether this error causes real malfunctions of the program. The current solution sets a number of requirements for the original polygonal grid of arteries, by which the spreading of the radiopaque substance is simulated. If the requirements are not met, the program may fall, or obviously incorrect work. Some of these requirements are derived analytically, and some - empirically. It is possible that this second part of the requirements is growing just from incorrect work with floating point numbers. It should be noted that not all found cases of using an exact comparison of floating-point numbers were an error.



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



Note. It is possible to set the alert level using the settings. For example, if you think that the V550 diagnostics deserves 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 a specific diagnosis").

Conclusion

Now you know how to start examining analyzer alerts, looking at the most interesting ones. And do not forget to look in the documentation to get acquainted with the detailed description of the warnings. Sometimes it happens that behind a seemingly seemingly precarious warning lies 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 do you quickly check out the PVS-Studio analyzer for the C and C ++ code?