What you have just opened is the article you should link to in your Twitter or post in your favorite programmer public. This will benefit both us and the open-source software community. We analyze open-source projects and help make them better to get programmers all over the world to learn about PVS-Studio. Meanwhile, we write interesting and helpful articles. The more people get to know about them, the more pleased we'll be doing that and the more projects we will check. Everyone profits - sounds great, doesn't it?

The idea of analyzing open-source projects for the sake of promoting one's products isn't something we have invented. But nobody else does exactly what we do - publish detailed reports of our checks.

You can often see some project mentioned to have been analyzed by an X static analyzer. But these are usually just descriptive generalizations or a mix of the analyzer's warnings and diff output. It's not interesting to read hollow ads. Reports about fixes done in the code are not informative for people unfamiliar with it, either, and so they are of little help in understanding what the bug is about.

We are no lazybones. We try to describe the error in every detail, explain how to fix it and avoid it if possible. Here are the results of our work over the many years:

Updatable list of articles where we tell our readers about the bugs found by PVS-Studio in open-source projects.

Reading our articles is not only interesting but also useful. Even experienced programmers can learn from them about new bug patterns and dark corners of the C++ language.

To make it interesting, we prefer well-known programs. For example, you can learn about bugs found in the code of the following projects:

  • CoreCLR
  • LibreOffice
  • Qt
  • Clang
  • Chromium


We do not write about every single project we have checked: Some of them are too small or have too few interesting bugs. But we always report these bugs to the project authors and add the errors into our bug database. This base can be used as a source of inspiration for many articles (example). So we do recommend that you use this resource to pick bug samples when preparing presentations, articles, books, or when developing coding standards.

We wish you bugless code! Keep track of new checks by following us in Twitter: @Code_Analysis.