This is exactly the case when a reply to a comment turned into a small blog post. The power of the PVS-Studio analyzer is not only in finding particular errors but also in the process of finding them.
From time to time, readers of our articles leave comments, saying that a particular error can be found without using PVS-Studio, simply by enabling the corresponding compiler warning. Yes, that's right. However, in practice, these compiler warnings are not so easy to use.
If everything was so simple, there would be no base of errors examples found by our team in open projects. At the time of writing this note, we have spotted more than 14000 bugs in projects such as Qt, Chromium, CMake, GTK 4. By the way, the code of the compilers (GCC 10, Clang 11) is not an exception. It's thought-provoking :).
Why were the errors waiting for PVS-Studio? After all, some of them may be quite well detected by compilers. The answer is obvious: it's challenging to up and enable all these warnings. It's difficult to work with too much noise.
Besides the fact that PVS-Studio has more diagnostic capabilities than compilers do, there are two other important advantages:
Our team works hard to reduce the number of false positives. However, there's no guarantee that you won't get a great number of meaningless warnings in the first analyzer run on a random project. For example, in a C project, a couple of failed macros are enough to ruin the whole picture and lead to thousands of false warnings.
It should be noted that if you have such a situation working with PVS-Studio, that's not a problem. Here's a case example of a small setup for a C++ project resulted in only 10-15% of the false warnings. It's happening thanks to comments, suppressing warnings in macros, and other various settings. It's usually not that easy with compilers. As a result, it's easier to find errors with PVS-Studio, rather than a compiler.
Check the following article: How to introduce a static code analyzer in a legacy project and not to discourage the team if you're curious about the process of static analyzer integration into large project development.
Merged - thank you. It's in some new code we're not yet using, and it's a missed simple compiler warning actually - it doesn't really demonstrate the power of PVS, re the first post. When we eventually fix all the tiny "fscanf return value ignored" style warnings leftover, we may treat warnings as errors in the future to spot these sort of things earlier.
Yes, this error may definitely be found by a compiler. But the fact remains that it was found using the PVS-Studio analyzer. A compiler use for these purposes is still only a dream and requires a lot of work.
If you enable the fourth level of warnings (/W4) in Visual C++, then one of the messages will certainly indicate the described error. But to do this, you need to break through all 150 warnings:
The PVS-Studio analyzer also generates about 150 General Analysis warnings, but at the same time, it separates the important from the secondary more clearly. At the first certainty level, there are only 3 warnings, one of which indicates the same error of using an uninitialized variable:
I suggest not looking forward to a bright future when the compiler can be set up for the maximum error search mode. Use the PVS-Studio static analyzer and find as many errors as possible at once. To start using the analyzer regularly, apply the mechanism of warnings mass suppression (set the baseline). For convenience, PVS-Studio can be integrated into various CI systems. Further, suppressed warnings can be viewed as uncritical technical debt, which can be gradually disposed of. Once again, check this article for more details.
If you are an open source code developer, you can use the free licensing option.
If you still have questions, then perhaps you'll find most of the answers in the following article: Why You Should Choose the PVS-Studio Static Analyzer to Integrate into Your Development Process. Thank you for your attention.