Common information on working with the PVS-Studio analyzer

Abstract

The article is a tutorial on working with the PVS-Studio code analyzer on the Windows platform. This section contains examples of how to perform most common tasks when working with the PVS-Studio analyzer.

With the features of using the PVS-Studio analyzer for Linux, you can see the documentation section "How to run PVS-Studio on Linux".

System requirements and installation of PVS-Studio

The PVS-Studio analyzer on the Windows platform integrates into Microsoft Visual Studio 2017, 2015, 2013, 2012, 2010 development environments. You may learn about the system requirements for the analyzer in the corresponding section of the documentation.

After you obtain the PVS-Studio installation package, you may start installing the program.

Figure 1 - Installation of PVS-Studio

Figure 1 - Installation of PVS-Studio

After approval of the license agreement, integration options will be presented for various supported versions of Microsoft Visual Studio (figure 2). Integration options which are unavailable on a particular system will be greyed-out. In case different versions of the IDE or several IDEs are present on the system, it is possible to integrate the analyzer into every version available.

Figure 2 -PVS-Studio integration options for various IDEs

Figure 2 -PVS-Studio integration options for various IDEs

To make sure that the PVS-Studio tool was correctly installed, you may open the About window (Help/About menu item). The PVS-Studio analyzer must be present in the list of installed components (Figures 3, 4).

Figure 3 - About Microsoft Visual Studio window with the PVS-Studio component installed

Figure 3 - About Microsoft Visual Studio window with the PVS-Studio component installed

Introduction into PVS-Studio

Let's open the test project inside Microsoft Visual Studio (on any IDE version available). After the project is opened, let's start the analysis for all files by "PVS-Studio -> Check -> Solution" IDE main menu command (figure 4).

Figure 4 - launching analysis by PVS-Studio

Figure 4 - launching analysis by PVS-Studio

After launching the verification, the progress bar will appear with the buttons Pause (to pause the analysis) and Stop (to terminate the analysis). Potentially dangerous constructs will be displayed in the list of detected errors during the analysis procedure (Figure 5).

Figure 5 - Project analysis

Figure 5 - Project analysis

The term "a potentially dangerous construct" means that the analyzer considers a particular code line a defect. Whether this line is a real defect in an application or not is determined only by the programmer who knows the application. You must correctly understand this principle of working with code analyzers: no tool can completely replace a programmer when solving the task of fixing errors in programs. Only the programmer who relies on his knowledge can do this. But the tool can and must help him with it. That is why the main task of the code analyzer is to reduce the number of code fragments the programmer must look through and decide what to do with them.

Once the code analysis is over, you may look through the messages.

Fixing errors

After getting the list of diagnostic messages from the analyzer, you may study them. Let's look at the first error:

error V579 The memset function receives the pointer and its size as arguments. It is possibly a mistake. Inspect the third argument. sample1.cpp 7

And here is the corresponding source code:

  data->num = 10000;
  data->sum = 10000;
  memset(data, 0, sizeof(data));

The issue here is that the 'data' structure will not be filled with zeroes completely. The mistake is that the 'sizeof(data)' expression is incorrect. To fix the issue, the correct size of the 'data' structure should be passed to the 'memset' function:

    memset(data, 0, sizeof(*data));

You may learn about this diagnostics type in the help system. If you click on the cell containing the code of an error in the 'Code' column, you will see a window with the description for this error (figure 6 is for Microsoft Visual Studio IDE):

Figure 6 - Detailed description of an error and ways of fixing it

Figure 6 - Detailed description of an error and ways of fixing it

After applying the fix, let's restart the analysis to see that there is one less item in the diagnostic warnings. It means that the issue is fixed. In the same way we should review all the diagnostic messages and fix those fragments in the code where problems are possible.

How to work with the list of diagnostic messages

Of course, in real large projects, there will be not dozens but hundreds or even thousands of diagnostic messages and it will be a hard task to review them all. To make it easier, the PVS-Studio analyzer provides several mechanisms. The first mechanism is filtering by the error code. The second is filtering by the contents of the diagnostic messages' text. The third is filtering by file paths. Let's examine examples of using filtering systems.

Suppose you are sure that the diagnostic messages with the code V112 (using magic numbers) are never real errors in your application. In this case you may turn off the display of these diagnostic warnings in the analyzer's settings:

Figure 7 - Turning off some diagnostic messages by code

Figure 7 - Turning off some diagnostic messages by code

After that, all the diagnostic warnings with the code V112 will disappear from the error list. Note that you do not need to restart the analyzer. If you turn on these messages again, they will appear in the list without relaunching the analysis as well.

Now let's study another way of filtering by the text of diagnostic messages. Let's return to our example. One of the issues found by the analyzer is that the 'N >= 0' expression always equals true:

V547 Expression 'N >= 0' is always true. Unsigned type value is always >= 0. sample1.cpp 18

Here is the corresponding source code:

if (TEST(N))
{
  data->num = N;
}

Of course it is possible to just fix this code, and the diagnostic message will disappear. Here the problem is, the macro that is used here can become correct on a different platform. So, if such a code occurs frequently and there is an absolute certainty about its correctness, then it is possible to disable the display of messages containing the 'Expression 'N >= 0' is always true' string. It can be accomplished through the Keyword Message Filtering options page:

Figure 8 - Turning off some diagnostic messages by their text

Figure 8 - Turning off some diagnostic messages by their text

After that, all the diagnostic messages whose text contains that expression will disappear from the error list, without the necessity of restarting the code analyzer. You may get turn them on back by simply deleting the expression from the filter.

The last mechanism of reducing the number of diagnostic messages is filtering by masks of project files' names and file paths.

Suppose your project employs the Boost library. The analyzer will certainly inform you about potential issues in this library. But if you are sure that these messages are not relevant for your project, you may simply add the path to the folder with Boost on the page Don't check files (Figure 9):

Figure 9 - Setting message filtering by file location and names

Figure 9 - Setting message filtering by file location and names

After that, the diagnostic messages referring to the files in this folder will not be shown. This option requires restarting the analysis.

Also, PVS-Studio has the "Mark as False Alarm" function. It enables you to mark those lines in your source code which cause the analyzer to generate false alarms. After marking the code, the analyzer will not produce diagnostic warnings on this code. This function makes it more convenient to use the analyzer permanently during the software development process when verifying newly written code.

Thus, in the following example, we turned off the diagnostic messages with the code V640:

  for (int i = 0; i < m; ++i)
    for (int j = 0; j < n; ++j)
      matrix[i][j] = Square(i) + 2*Square(j);
    cout << "Matrix initialization." << endl; //-V640
...

This function is described in more detail in the section "Suppression of false alarms".

There are also some other methods to influence the display of diagnostic messages by changing the code analyzer's settings but they are beyond the scope of this article. We recommend you to refer to the documentation on the code analyzer's settings.

Is it necessary to fix all the potential errors the analyzer informs about?

When you have reviewed all the messages generated by the code analyzer, you will find both real errors and constructs which are not errors. The point is that the analyzer cannot detect 100% exactly all the errors in programs without producing the so called "false alarms". Only the programmer who knows and understands the program can determine if there is an error in each particular case. The code analyzer just significantly reduces the number of code fragments the developer needs to review.

So, there is certainly no reason for correcting all the potential issues the code analyzer refers to.

But you must attempt to fix as many fragments as possible. It is especially relevant when the static analyzer is used to verify an application not once, for instance, when you port it to a 64-bit system, but regularly with the purpose to find new errors and inefficient constructs brought into a project. In this case, correcting fragments which are really not errors and setting the analyzer for suppressing particular types of errors will significantly reduce time for the next launch of the analyzer.


Do you make errors in the code?

Check your code
with PVS-Studio

Static code analysis
for C, C++ and C#

goto PVS-Studio;