Our website uses cookies to enhance your browsing experience.
to the top
close form

Fill out the form in 2 simple steps below:

Your contact information:

Step 1
Congratulations! This is your promo code!

Desired license type:

Step 2
Team license
Enterprise license
** By clicking this button you agree to our Privacy Policy statement
close form
Request our prices
New License
License Renewal
--Select currency--
* By clicking this button you agree to our Privacy Policy statement

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

close form
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

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

close form
check circle
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

Comments (0)

Next comments next comments
close comment form