Our website uses cookies to enhance your browsing experience.
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.
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:
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.
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).
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.
Yes. PVS-Studio for Linux.
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.
0
0
0
Your message has been sent. We will email you at
If you do not see the email in your inbox, please check if it is filtered to one of the following folders:
0