Why did you need a static analyzer message suppression system

Each software product has its own history of origin and development. A project may be new and small or be commercially successful for a dozen years and have thousands of source files. When introducing a static analyzer, besides the technical issue of integration into the project, other important questions arise: how to handle the analysis results correctly? Should I correct all the warnings of the analyzer? ... This article will tell about a new way of processing the results of the work of static analyzers.

The role of the standard static code analyzer is performed by the used compiler. A small number of its diagnostic rules covers only the most common cases of suspicious code writing, almost all of which are not only recommended to be corrected, but are mandatory for correction in many companies.

Nevertheless, the compiler does not generate so many messages, among which it will not be difficult to see the new warning and, if necessary, correct it. Specialized static analyzers have many diagnostic rules and even on small projects they can generate a huge number of warnings.

The third-party static code analyzer is not a tool, all warnings of which need to be fixed. Some diagnostic rules are based on heuristic methods and often give false positives. Some suspicious places may be a special idea of ​​the programmer, writing the code had its own reasons and it is not planned to correct this place.
')
Disabling such diagnostic rules is not a good solution. With the help of them you can detect errors that are extremely difficult to notice when reviewing the code. And, despite the false alarms, a real error in the future may appear. Then the question is how to skip some warnings and see only new ones.

In such situations, you can use warning suppression by typing the appropriate comment at the end of the line so that the analyzer misses this place. But this method often causes mistrust, as it implies automatic marking of a large amount of source code, and there is no question of manual marking in large projects.

Thus, the possibility of suppressing messages of static code analyzers on large projects was required. It was necessary to highlight new warnings among all, based only on previous launches of the analyzer.

One diagnostic message contains the following information: the name of the diagnosis, the type and level of the warning, the explanatory message, the name of the scanned file, the line number of the file and the hash of several lines.

To match warnings when changing the source code, all parameters of the diagnostic message should be considered, with the exception of the line number, since it changes unpredictably and at the slightest modification of the file.

In the PVS-Studio static analyzer, the use of this functionality is implemented in the form of the “Analyzer Message Suppression” dialog box (Fig. 1).
Figure 1 - Alert Suppression Control Dialog Box

The Suppress Current Messages button performs the initial markup of analyzer messages and saves the result to local * .suppress files. After that, during subsequent checks of the source code, the received messages will be compared with messages from these files and only new warnings will be displayed in the IDE output window of the PVS-Studio plugin (Fig. 2).Figure 2 - Several new analyzer alerts

The tick “Display Suppressed Messages in PVS-Studio Output Window” in Figure 1 allows you to enable the display in the output window of PVS-Studio and filtered messages, the status of which can be changed if necessary (Figure 3).
Figure 3 - All analyzer warnings

Conclusion

The new mechanism implemented in the PVS-Studio static analyzer is an addition to the existing markup method with source code comments. If a false warning points to a line in the header file that is included in many source files and different projects, then it’s better to mark such a place once with a comment. Thanks to these features, the regular use of static analysis becomes easier to use.