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.

>
>
Readers' FAQ on Articles about PVS-Stud…

Readers' FAQ on Articles about PVS-Studio, 2015

Jan 05 2015

In the comments to our articles, readers would often ask the same questions. We decided to make a FAQ to refer people to it instead of giving the same answers every time. Because we - the developers of the static code analyzer PVS-Studio - regularly publish a lot of articles on various subjects, including the checks of open-sources projects performed by our tools.

Have you reported the bugs to the project developers? Have you sent them a patch?

When checking open-source projects, we almost always report the results to their authors. If we publish such a report as an article, we try to send the link to it to the developers. If there are too few bugs in a project to write an article about, we still report whatever results we've got to the authors. Or rather, we try to - sometimes developers don't (strange as it may sound) have any contacts, or their bug trackers don't accept messages, or you need to enter a captcha which no one can solve.

That's why we never send patches. There are a few reasons for that:

  • We are not familiar with the code and therefore cannot be sure if all the bugs we catch are really bugs. To understand that, we would need to study the project very closely.
  • Even with obvious bugs, we often can't say for sure how to fix them.
  • Finally, we pursue but one goal with our articles - to demonstrate the capabilities of the analyzer we develop. That is, we want to prove that our tool can find bugs in a real-life, living code. We don't aim at fixing bugs - we aim at proving that our tool can find them.

Was it the trunk (stable) version of the project you checked? Well, you should have checked the stable (trunk) version instead!

With the probability of 99%, it was the trunk version. But it doesn't really matter! The worst idea one could come up with is to try fixing bugs in the code relying on our articles.

We may make mistakes treating certain diagnostic messages as bugs, and we may miss genuine bugs. The funniest thing is when two volunteers independently try to fix one and the same code after reading the article. Such things already happened. For example, we mentioned in an article that the 2-nd and 3-rd arguments of the memset() function were mixed up. The first volunteer changed those arguments - and it was alright. Then the second volunteer changed them again and it all got back to how it had been before. :)

So we'd rather take a safer path. The developers responsible for the project discussed in an article will read it and see that there are some bugs in their code. Then they will check it with PVS-Studio and fix whatever bugs they find themselves.

You should also keep in mind that it takes us some time to check a project and write an article (it can't be done in just 15 minutes, after all), and the code is very likely to change during this time. That's why you shouldn't rely on the article. At the very least, code line numbers may have been changed.

The goal of our articles is to show the analyzer's capabilities on a real, living software product. And to achieve this goal, it doesn't matter which version we check.

Haven't you checked the project X?

Perhaps we already checked it and published an article about that. If so, you are likely to find it in the list given in the article "Updatable List of Open-Source Projects Checked with PVS-Studio". We check some of the projects more than once because they are actively evolving and we can reveal more and more new bugs in them.

It is also possible that we already checked the project but there were too few bugs for an article. These reports you can try to find in our database of bugs found in open-source projects through static analysis.

Finally, it may also happen that we checked the project and didn't find any bugs in it. It is usually the case with very high quality projects written by 1-2 programmers (and therefore of a small size).

Why so LITTLE?

Article about project check is not a comprehensive check report. In this article only the most interesting and suspicious places, at the author's point of view, are covered. For more detailed analysis of source files you can analyze project by yourself. Developers of checked projects can mail their suggestions to support@viva64.com.

Do you ship Linux-versions of PVS-Studio?

Yes. PVS-Studio for Linux.

Have you checked PVS-Studio with PVS-Studio? Can I read an article somewhere about the results of those checks?

We regularly check our static analyzer by itself.

First, we use the incremental analysis mode. It means that the analyzer runs automatically on freshly recompiled files. So if any bugs (which the analyzer is capable to detect) occur, they get fixed right away. Because of that, they don't get into the version control system or the bug tracker.

Second, we have set up our analyzer so that it checks its own source codes automatically every night. So even if we missed the incremental analysis results for some reason, all the detected and not yet fixed bugs are reported to us by e-mail.

So, although we regularly check our own code, we will never be able to publish an article about bugs found by the analyzer in itself.

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