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.

>
>
PVS-Studio Output Window vs plain text …

PVS-Studio Output Window vs plain text stdout

Oct 12 2011

While communicating with programmers who ponder over the idea of using a static code analyzer, you may often here them say: "You don't need any special interface for a tool of that kind. A simple command line tool will do. And you can always save stdout into a file". I want to show you what is wrong about this way of thinking by the example of PVS-Studio's Output Window.

0111-Output_window_vs_plain_text_stdout/image1.png

So, this is the minimum information you can see in a report file of any static code analyzer or compiler that generates a list of error messages:

  • error code;
  • message text;
  • file name;
  • line number.

Really, it seems that you can well arrange this information in a form of a text file or stdout. Most compilers actually do it that way. And what about static analyzers? Maybe they can "spit it all into stdout" too? And how do you tell the difference?

The difference between static analyzers and compilers regarding results representation is only one yet crucial parameter. This is the number of messages output.

When you deal with a compiler, you don't get too many messages from it. Usually there are several error messages (not more than ten of them) and a bit more (about several dozens at most) warnings. Complete absence of warnings in a project is considered a good style. Of course there are cases when there are much more compilation errors but they are rare compared to the total number (when porting the code to a different platform or when libraries being used undergo global changes). So, once again, a user gets just a few error messages in the usual operation mode.

Handling a static analyzer is quite a different thing. Usually a static analyzer is "being set on" an already existing project. And the larger the project is, the greater urge the team feels to use a static analyzer. What follows from that? A static analyzer will generate hundreds of messages for a small project, thousands of messages for a medium project, and a large project (the team has been working for years on) will cause even dozens of thousands of messages. You have to handle all these messages somehow, analyze them and so on.

So what is the difference between the contemporary output window of a static analyzer (for example, in PVS-Studio) and plain text stdout? I will first enumerate common things many of which can be found in the Error List window in Visual Studio (although stdout cannot do even that):

  • Code navigation. Imagine you sit down and start studying a new tool. It's one thing when you have to search for code lines in the project manually or create a special utility to turn the log into something that could be used by the development environment for navigation purposes. And it's quite a different thing when you just click twice on a diagnostic message. You agree that studying of a new tool in the first case might end without really having started, don't you?
  • Sorting. At first sight this operation is not so much necessary. But if you want to handle a large project, you will really need it.
  • Quick and convenient access to the help system by the error code.

And now let's see what capabilities significant especially for a static analyzer are provided by a window.

  • You can mark some messages as false reports ("Mark As False Alarm"). For instance, in PVS-Studio this feature is implemented through adding a special comment of the "//-V124" kind into the code. But it's not convenient to add this code manually (although nothing prevents you from doing this), that's why you may simply click the "Mark As False Alarm" command in the window. Simple stdout won't let you use this mechanism with that convenience.
  • You may filter messages on the fly. You may hide or display messages with a certain error code or messages containing certain words and so on. It is very convenient since there are a lot of messages and relaunching the analyzer is a long process. Of course, you may argue that there are wonderful unix-utilities like grep, sed, awk and so on, but they are, to put it mildly, for true fans.

Even when static analysis gets integrated into a project and the number of messages generated is few, it's still much more convenient to handle them through a specialized window.

The five advantages of message output window I have listed show it very well that it's much more convenient to handle a static analyzer when it has such an interface. Phrases like "stdout is enough" result from lack of understanding. It's "enough" only in theory. But in practice it will be impossible to use a tool until you create a similar infrastructure for yourself (the capability to navigate on the code, sort and filter messages, etc.).

Popular related articles
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…
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 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…
PVS-Studio for Java

Date: Jan 17 2019

Author: Andrey Karpov

In the seventh version of the PVS-Studio static analyzer, we added support of the Java language. It's time for a brief story of how we've started making support of the Java language, how far we've co…
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…
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…
Free PVS-Studio for those who develops open source projects

Date: Dec 22 2018

Author: Andrey Karpov

On the New 2019 year's eve, a PVS-Studio team decided to make a nice gift for all contributors of open-source projects hosted on GitHub, GitLab or Bitbucket. They are given free usage of PVS-Studio s…
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…
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…

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