To get a trial key
fill out the form below
Team License (standard version)
Enterprise License (extended version)
* By clicking this button you agree to our Privacy Policy statement

** This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.
Request our prices
New License
License Renewal
--Select currency--
USD
EUR
GBP
RUB
* By clicking this button you agree to our Privacy Policy statement

** This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.
To get the licence for your open-source project, please fill out this form
* By clicking this button you agree to our Privacy Policy statement

** This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.
To get the licence for your open-source project, please fill out this form
* By clicking this button you agree to our Privacy Policy statement

** This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.
I am interested to try it on the platforms:
* By clicking this button you agree to our Privacy Policy statement

** This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.
Message submitted.

Your message has been sent. We will email you at


If you haven't received our response, please do the following:
check your Spam/Junk folder and click the "Not Spam" button for our message.
This way, you won't miss messages from our team in the future.

>
>
Why We Need the Suppression Mechanism f…

Why We Need the Suppression Mechanism for Analyzer-Generated Messages

Dec 04 2014

Every software product has its own origin and development history. A project may be new and small or it may have a dozen of years of commercial success behind it and include thousands of source files. When integrating a static analyzer into the development process, apart from the technical issues of tool integration as such, other important questions also arise such as: how to process analysis results correctly? should we have all the analyzer-generated warnings fixed?... In this article, we are going to talk about a new method of processing static analyzers' output.

0294_Suppresser/image1.png

The compiler you use acts as a standard static code analyzer. The small set of its diagnostic rules covers only the most common cases of suspicious code almost all of which are not only desirable but demanded to be fixed in most companies.

However, the compiler doesn't generate too many warnings and you won't have any troubles distinguishing a fresh one among them and fix it if necessary. Unlike that, specialized static analyzers carry numbers of diagnostic rules onboard and may generate huge amounts of warnings even on small projects.

A third-party static code analyzer is not kind of a tool every single warning of which must be fixed. Some of the diagnostics are based on heuristics and output false positives quite often. And some of the fragments they find suspicious may have been written consciously that particular way, the programmer having his own reasons for that and never meaning to fix such code.

Disabling such diagnostic rules is not a good idea. They can help you find errors that are too difficult to catch through ordinary code review. Despite false positives there is still a risk that a genuine error will reveal itself later. Then we face the question how to skip certain warnings and see only new ones.

To solve this task, you can use the warning suppression mechanism by adding a special comment at the end of a code line for the analyzer to skip this piece during the next runs. But programmers don't seem to trust this technique as it implies automatic marking of a large bulk of source code while manual marking is never an option for large projects.

Thus, users faced a need for a mechanism to suppress static code analyzers' messages in large projects; a mechanism to allow them to single out new warnings among the entire amount based only on the previous analyzer runs.

One diagnostic message contains the following data: a diagnostic name, warning type and severity level, message explanation, file name, line number and hash sums of a few adjacent lines.

To compare warnings after the source code is changed, it is necessary that all the parameters of the diagnostic message should be taken into account save for the line number as it changes unpredictably after a slightest alteration of the file.

In the PVS-Studio static analyzer, the mechanism of using this feature is implemented in the form of the dialog window "Analyzer Message Suppression" (Figure 1).

0294_Suppresser/image2.png

Figure 1 - Warning suppression management dialog window

The "Suppress Current Messages" button is used to do the initial marking of the messages and save the result into local *.suppress files. From that moment on, messages generated during the next checks will be compared to those contained in these files so that only new warnings are displayed in the output window of the PVS-Studio IDE plugin (Figure 2).

0294_Suppresser/image3.png

Figure 2 - A few new analyzer warnings

Ticking the "Display Suppressed Messages in PVS-Studio Output Window" checkbox shown in Figure 1 allows you to enable displaying filtered off messages in PVS-Studio's output window as well and change their status if necessary (Figure 3).

0294_Suppresser/image5.png

Figure 3 - The full list of analyzer warnings

Conclusion

The new mechanism implemented in the PVS-Studio static analyzer supplements the current method of source code marking through comments. If you've got a false warning pointing to a line in a header file included into many source files and different projects, you'd better mark this fragment with a comment once. Thanks to these features, static analysis becomes even more convenient for regular use.

Popular related articles
PVS-Studio ROI

Date: Jan 30 2019

Author: Andrey Karpov

Occasionally, we're asked a question, what monetary value the company will receive from using PVS-Studio. We decided to draw up a response in the form of an article and provide tables, which will sho…
How PVS-Studio Proved to Be More Attentive Than Three and a Half Programmers

Date: Oct 22 2018

Author: Andrey Karpov

Just like other static analyzers, PVS-Studio often produces false positives. What you are about to read is a short story where I'll tell you how PVS-Studio proved, just one more time, to be more atte…
Static analysis as part of the development process in Unreal Engine

Date: Jun 27 2017

Author: Andrey Karpov

Unreal Engine continues to develop as new code is added and previously written code is changed. What is the inevitable consequence of ongoing development in a project? The emergence of new bugs in th…
The Evil within the Comparison Functions

Date: May 19 2017

Author: Andrey Karpov

Perhaps, readers remember my article titled "Last line effect". It describes a pattern I've once noticed: in most cases programmers make an error in the last line of similar text blocks. Now I want t…
Technologies used in the PVS-Studio code analyzer for finding bugs and potential vulnerabilities

Date: Nov 21 2018

Author: Andrey Karpov

A brief description of technologies used in the PVS-Studio tool, which let us effectively detect a large number of error patterns and potential vulnerabilities. The article describes the implementati…
Appreciate Static Code Analysis!

Date: Oct 16 2017

Author: Andrey Karpov

I am really astonished by the capabilities of static code analysis even though I am one of the developers of PVS-Studio analyzer myself. The tool surprised me the other day as it turned out to be sma…
Characteristics of PVS-Studio Analyzer by the Example of EFL Core Libraries, 10-15% of False Positives

Date: Jul 31 2017

Author: Andrey Karpov

After I wrote quite a big article about the analysis of the Tizen OS code, I received a large number of questions concerning the percentage of false positives and the density of errors (how many erro…
The Last Line Effect

Date: May 31 2014

Author: Andrey Karpov

I have studied many errors caused by the use of the Copy-Paste method, and can assure you that programmers most often tend to make mistakes in the last fragment of a homogeneous code block. I have ne…
The way static analyzers fight against false positives, and why they do it

Date: Mar 20 2017

Author: Andrey Karpov

In my previous article I wrote that I don't like the approach of evaluating the efficiency of static analyzers with the help of synthetic tests. In that article, I give the example of a code fragment…
The Ultimate Question of Programming, Refactoring, and Everything

Date: Apr 14 2016

Author: Andrey Karpov

Yes, you've guessed correctly - the answer is "42". In this article you will find 42 recommendations about coding in C++ that can help a programmer avoid a lot of errors, save time and effort. The au…

Comments (0)

Next comments

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.
This website uses cookies and other technology to provide you a more personalized experience. By continuing the view of our web-pages you accept the terms of using these files. If you don't want your personal data to be processed, please, leave this site.
Learn More →
Accept