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

Request our prices
New License
License Renewal
--Select currency--
* By clicking this button you agree to our Privacy Policy statement

Free PVS-Studio license for Microsoft MVP specialists
* By clicking this button you agree to our Privacy Policy statement

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

I am interested to try it on the platforms:
* By clicking this button you agree to our Privacy Policy statement

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.

I've sent a PVS-Studio text log to the …

I've sent a PVS-Studio text log to the project authors! Did I really help?

Nov 10 2016

Quite often, people who have just started using our analyzer, do the following: they check a well-known project, save the results of the analysis in a text file and send it to the developers thinking that they did a good job. After all, they help to find bugs! I want to tell, why you shouldn't do that.

Since the creation of PVS-Studio, we have tried hard to make it as functional and user-friendly as possible. One of the key things when working with the analyzer is handling the analysis results. Quite often, the way the analysis results are interpreted, influences the overall impression and the efficiency of the use.

So, what's the problem?

At times people don't understand how to correctly use the analyzer results and sometimes - the analyzer itself. Obviously, that's our fault. However, we are trying to make the interface as intuitive as possible, by adding utilities for handling the analysis results to the distribution kit and implementing features to enhance the analyzer report usability. We also provide detailed documentation for all our features, but does anyone really read it?

The problem is in the interpretation of the results. At this point, a log file is provided as an xml-file; some developers try working with it manually. This is a wrong approach; .plog-files are not intended for manual processing! The log file, obtained in the result of the analyzer work, is a collection of information that can be processed in various of ways, by adjusting the analysis results in the most convenient way. On condition that the developer uses necessary utilities. Everything is ready to use - you should just start!

The truth is out there (c)

What features can improve the usability of the log?

  • Disabling diagnostic rules. A number of diagnostic rules may be irrelevant for your project. The best practice is to disable these rules - this allows you to ignore those warnings that are uninteresting for you;
  • Excluding directories from the analysis. You can specify a certain directory, whose file analysis you are not interested in. It would be useful to exclude from the analysis, for example, third-party source code;
  • False positive markup. Using this mechanism, you can mark up false positives of the analyzer; they will not appear in the log and won't hamper its viewing;
  • Sorting the warnings by the severity level. Will allow differentiating the most and least critical errors and thus simplifying the prioritization in the warnings handling.
  • Filtering messages. There are a lot of possible options of filtering: by the error code, by the project name, by the severity level, etc. This will allow filtering the warnings to work with them more comfortably;
  • Conversion to other formats. For example, you can convert the log into an html-file that can be later used for e-mail notification, for example.


Don't try to view a raw log or "reinvent the wheel" for handling the analysis results - most likely, everything you need is already implemented, you should just use them. The documentation gives information about the tools and means for effective using of the analyzer. If there are any questions after reading the documentation - feel free to contact us, we'll be glad to help:

Oh, and the most important! Do not send anyone a text log of the PVS-Studio report! You will do more harm than good for the project authors (they won't spend time, sorting out the garbage, anyway). For us it won't be great as well - some may think that PVS-Studio works like a lint-utility from the 80-ies.

Popular related articles
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 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…
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…
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…
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…
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…
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…
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…
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…

Comments (0)

Next comments
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 →