Readers' FAQ on Articles about PVS-Studio, 2015

Evgeniy Ryzhkov
Articles: 109

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

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.

Use PVS-Studio to search for bugs in C, C++, and C# code

We offer you to check your project code with PVS-Studio. Just one bug found in the project will show you the benefits of the static code analysis methodology better than a dozen of the articles.

goto PVS-Studio;

Evgeniy Ryzhkov
Articles: 109

Do you make errors in the code?

Check your code
with PVS-Studio

Static code analysis
for C, C++, and C#

goto PVS-Studio;
We use cookies for the analysis of events to improve our content and make user interaction more convenient. By continuing the view of our web-pages you accept the terms of using these files. You can find out more about cookie-files and privacy policy or close the notification, by clicking on the button. Learn More →
Do not show