15000 bugs in open-source projects
The number of bugs in our bug list has exceeded 15000. This is exactly the number of bugs found by the PVS-Studio team in various open-source projects. Most excitingly, our bug collection is just a by-product of writing articles.
Our team has been writing articles about open-source project checks since the earliest days of the PVS-Studio code analyzer. This is a great way to promote our tool. There are no meaningless marketing words — developers do not like them. There is only a clear demonstration of particular bugs in real projects.
We also make collections from the best examples found:
Articles about errors found in projects benefit everyone. We popularize the methodology of static code analysis, and developers of projects have the opportunity to fix errors in their code. By the way, the authors of open-source projects have several options to use PVS-Studio for free.
We believe that our team has greatly contributed to the development of open-source projects over the years. We have already detected more than 15,000 errors. And it's hard to imagine how many bugs the projects' authors fixed with the help of free PVS-Studio licenses. It's good to know that the PVS-Studio analyzer helped to make code of many projects more reliable and safer.
We carefully add all the errors that we find to the bug list. You can find it here.
This collection of bugs can serve as a resource for various studies. So, I suggest that authors who write books and articles about code quality pay attention to the collection. For example, we have already noticed and described some patterns:
- Zero, one, two, Freddy's coming for you
- The last line effect
- The most dangerous function in the C/C++ world
- The evil within the comparison functions
Recently, we came up with another way to use our bug collection. We created a quiz for programmers, where you need to quickly find an error in a code fragment.
Here is a challenge for you: test your attentiveness when searching for a bug!
We will give you several code fragments with errors detected by the analyzer. If you manage to find them in under 60 seconds, you will score one point. Code fragments are short, so the 60-second limit is quite enough to find the errors. Enjoy and share the link with your teammates :)
P.S. People started asking questions, 'Where is the error in the code shown in the picture?'. The thing is that whether the code will work depends on the order in which the function arguments are evaluated. The context pointer can be null because the CreateSnapshotFile function takes arguments by value. This topic is complicated and is full of subtleties. If you want to understand better why the pointer might be null, we invite you to read the following article: "The code analyzer is wrong. Long live the analyzer!". The article describes a similar case and shows that GCC and Clang compilers generate different code.