Legacy code problems are familiar to the majority of software developers. The process of transforming code in legacy is inevitable, because progress in programming moves on. Projects either "die" forever, or require constant support and writing new functions. Thus, in any project in any programming language legacy code appears and brings different inconveniences when the process of further development. On the example of PVS-Studio, in this article I'll show you how to immediately start using the static code analyzer in your project.
To get current information about the mechanism of PVS-Studio warnings suppression follow the updated documentation page "Mass Suppression of Analyzer Messages".
To start, let us deal with the definition of legacy code and get acquainted with PVS-Studio static analyzer.
A term "legacy" is not always related to the age of code. Here are some of the most common definitions:
In any of these situations, developers are trying to modify code as carefully as possible when designing a project not to crash something. Additionally, a project can also use techniques and tools for writing more effective code of high quality. In this case, the old code may need to make much more changes. A using of modern standard language, conformity to a style guide and implementation of the static code analyzer are a few examples. Unfortunately, any of these ideas faces such an obstacle as legacy-code. It can be everywhere: it is impossible to separate it like test files or third-library files. Almost all tools, offering modifications of code, have the ability to mark up the code to disable the warnings, but in practice, this method cannot be applied. The first time you use such a tool, no one will let you mark up hundreds of thousands of comments in source code files - it is a very large amount of changed code because of which a view of changes in the systems of SCM (Source Control Management) will become very complicated. So, for PVS-Studio static analyzer a system of mass warnings suppression has been developed so that there would be no need to modify the project source files. This feature allows you to easily embed the analyzer in any project and IMMEDIATELY start to benefit from this, i.e. to find new bugs.
PVS-Studio is a static analyzer for bug detection in the source code of programs, written in C, C++ and C#. It can be run on Windows and Linux, integrate into build systems, various IDE systems and continuous integration systems.
Suppression mechanism is based on the use of special files "bases" of analyzer messages that are added next to the project. These files contain messages, tagged for this project as "unnecessary". During the next files checks of this type by the analyzer, it will automatically verify the existence of such files next to the project, and in case of their detecting will not show the messages, which are included in such a "base". We should note that a modifying of the source file that contains the tagged messages, and, in particular, lines shift, would not lead to the re-emergence of these messages. However, the edit of the line containing this message can lead to its repeated occurrence, since this message has already become "new".
For Microsoft Visual Studio PVS-Studio plugin is available, which is conveniently integrates in IDE. It allows you to run a check of the entire solution, specific projects or files, and it supports incremental analysis.
In PVS-Studio menu (Figure 1) a point "Suppress Messages ..." is available, which opens the window for working with suppressed analyzer warnings (Figure 2).
Figure 1 - PVS-Studio Menu in Visual Studio
Figure 2 - Window for analyzer warnings suppression
In the opening window, several actions are available:
To view analysis results in Visual Studio, there is a special window (Figure 3).
Figure 3 - PVS-Studio Output Window
Special window allows navigating along found warnings and jump to the code to fix them. PVS-Studio window provides a wide range of options for filtering and sorting the results. It is also possible to quickly navigate to the documentation of the selected diagnostic.
Additional opportunities of working with each message are available in the context menu by clicking the right mouse button on the message (Figure 4). Here the command for suppressing a selected warning is available. When menu entry at the already suppressed warning, false alarm mark will be available for reverting.
Figure 4 - A context menu of analyzer warning
PVS-Studio can be used regardless of the integrated Visual Studio development environment. Standalone provides opportunities to test the code regardless of the used compiler or build system, and then lets you work with analysis results providing a user interface similar to PVS-Studio plugin for Visual Studio (Figure 5).
Figure 5 - PVS-Studio Standalone
Standalone also allows you to work with the analyzer report, obtained by its direct integration into the build system, when a user does not have the Visual Studio environment.
Standalone menu for the analysis run and warnings suppression looks as follows (Figure 6).
Figure 6- Menu Tools of Standalone utility
When choosing a point in menu for analyzer run, the window "Compiler Monitoring (C/C++)" will appear (Figure 7).
Figure 7 - Dialog of build monitoring run
For analyzer warnings filtration, before the analysis a programmer has to specify the file with warnings, suppressed earlier. You can create and maintain such a file through the menu "Message Suppression...", which is the same as the one presented in a section about Visual Studio at Figure 2. After the completion of the analysis in a PVS-Studio window, only new errors will be shown. Without specifying the file, the analyzer will show all the results.
In Linux commands of suppression and filtration of analyzer warnings are performed only in console, but when their automating on server, the mechanism of suppression becomes very convenient.
There are several ways of using this mechanism, depending on the integration of the analyzer.
To suppress all analyzer warnings (first time and in subsequent occasions) you need to execute the command:
pvs-studio-analyzer suppress /path/to/report.log
Analysis of the project can be run as before. At the same time suppressed warnings will be filtered:
pvs-studio-analyzer analyze ... -o /path/to/report.log plog-converter ...
With this run suppressed warnings will be saved in the current directory in a file named uppress_base.json, which should be stored with the project. New suppressed warnings will be recorded to the file. If there is a need to specify a different name or location of the file, than the commands above may be supplemented by specifying the path to the file with suppressed warnings.
Direct integration might look as follows:
.cpp.o: $(CXX) $(CFLAGS) $(DFLAGS) $(INCLUDES) $< -o $@ pvs-studio --cfg $(CFG_PATH) --source-file $< --language C++ --cl-params $(CFLAGS) $(DFLAGS) $(INCLUDES) $<
In this mode, the analyzer cannot verify source files and filter them simultaneously. So, filtration and warnings suppression would require additional commands.
To suppress all the warnings, you must also run the command:
pvs-studio-analyzer suppress /path/to/report.log
To filter a new log, you must use the following commands:
pvs-studio-analyzer filter-suppressed /path/to/report.log plog-converter ...
File with suppressed warnings also has the default name suppress_base.json, for which you can optionally specify an arbitrary name.
SonarQube (formerly Sonar) is an open source platform for continuous inspection of code quality.
PVS-Studio plugin is available to users of this system. SonarQube combines the results of the analysis to a single dashboard, taking the history of runs, allowing to see the overall trend of software quality during a development. An additional advantage is the ability to combine the results of different analyzers.
So, after receiving the results of the analysis of one or more analyzers, you must go to the list of warnings and click on "Bulk Change", which opens the next menu (Figure 8).
Figure 8- A massive change of errors status
In this window, you can mark up all warnings of the analyzer as "won't fix" and further work only with new errors.
Configure static analysis on the build server and developers' computers. Correct new warnings of the analyzer and not let them accumulate. It is also worth to plan search and correction of errors among the suppressed warnings.
Additional control over code quality will help to ensure sending results by mail. It is possible to send warnings to only those programmers who made erroneous code using BlameNotifier utility, which is included in PVS-Studio distribution package.
For some users it may be convenient to load results in Jenkins or TeamCity using PVS-Studio plugin, and send a link to this page.
Missing of analyzer warnings on legacy-code is not the only scenario of presented mechanisms of using. Mass warnings suppression allows you to easily embed the analyzer in any project and immediately start to benefit from this, i.e. to find new bugs. Such implementation allows you to plan correcting of missed warnings in future, without distracting developers from performing their current tasks. This mechanism can also be used in future to suppress false alarms and warnings, which will not be corrected for various reasons.
This article discusses all the possible ways of suppressing analyzer warnings now. The collected material is based on documentation for the PVS-Studio analyzer, but the details on that topic were considered more than in documentation. General information may not be very informative for new users, so you should be familiar with the documentation below.
An alternative way of nullifying the number of analyzer warnings is a correction of all the analyzer warnings at the initial stage. Epic Games company used this way in Unreal Engine project. Details on this can be found in the article: How the PVS-Studio Team Improved Unreal Engine's Code
While communicating with people on forums, I noticed there are a few lasting misconceptions concerning the static analysis methodology. I decided to write a series of brief articles where I want to show you the real state of things.