📥 💽 🍹 Reasons to introduce PVS-Studio static code analyzer into the development process 🤵 🚥 🏣

PVS-Studio is a tool for finding errors and potential vulnerabilities in the source code of programs written in C, C ++, C # or Java. PVS-Studio belongs to the class of static application security testing (SAST) tools. The analyzer is focused on the practice of continuous integration (CI) and allows you to identify errors at the earliest stages when fixing them costs almost nothing.

Static code analysis

Software projects in the process of their development are becoming more and more. Examples:

Linux kernel 1.0.0: 176,000 lines of code
Linux kernel 5.0: 26,000,000 lines of code
Photoshop 1.0: 128,000 lines of code
Photoshop CS 6: 10,000,000 lines of code

As a project grows in size, its complexity grows faster than linearly. For this reason, as the size of the code base grows, so does the density of errors. One way to compensate for the growing complexity is to use static code analysis tools.

Static analyzer is a programmer's assistant program that performs a preliminary review of the code and indicates fragments of code that are likely to contain an error. Due to this, many errors can be corrected at an early stage, when the cost of fixing them is minimal.

Static analysis does not replace, but complements other defect detection methodologies, such as code reviews, unit tests, dynamic code analysis, regression tests, manual testing, and so on.

For example, if we are talking about code reviews , it is much better if the program detects simple errors. Then the programmers reviewing the code will be able to focus on more useful high-level checks of the algorithm, and will not be forced to read into the comparison functions . Moreover, as practice shows, many errors are very difficult to look for “with your eyes” and they are very likely to go through the code review phase unnoticed.

Another advantage of static analysis tools is the presence of a rich database of error patterns. They can find problems, the existence of which the programmer may not even be aware of. Some examples: V698 , V718 , V1023 .

PVS-Studio

We recommend implementing the PVS-Studio static code analyzer developed by us in the development process. The product runs on 64-bit systems on Windows, Linux, and macOS and can analyze code intended for 32-bit, 64-bit, and embedded ARM platforms.

At the time of publication of this article, the analyzer supports the following languages and compilers:

Windows Visual Studio 2010-2019 C, C ++, C ++ / CLI, C ++ / CX (WinRT), C #
Windows IAR Embedded Workbench, C / C ++ Compiler for ARM C, C ++
Windows QNX Momentics, QCC C, C ++
Windows / Linux Keil µVision, DS-MDK, ARM Compiler 5/6 C, C ++
Windows / Linux Texas Instruments Code Composer Studio, ARM Code Generation Tools C, C ++
Windows / Linux / macOS. GNU Arm Embedded Toolchain, Arm Embedded GCC compiler, C, C ++
Windows / Linux / macOS. Clang C, C ++
Linux / macOS. GCC C, C ++
Windows MinGW C, C ++
Windows / Linux / macOS. Java

The analyzer has detailed documentation in English and Russian. Descriptions of diagnostic rules contain examples of correct and incorrect code, as well as links to examples of real errors found in open source projects.

For the convenience of specialists who will use PVS-Studio as a SAST tool , the analyzer displays its warnings on Common Weakness Enumeration, SEI CERT Coding Standards and the MISRA standard. Compliance tables of PVS-Studio diagnostics to various standards:

The analyzer can be used both independently and integrate with Visual Studio and IntelliJ IDEA. In addition, recently a number of our customers have been using PVS-Studio as part of SonarQube. PVS-Studio, being connected as a plug-in to SonarQube, is an additional source of diagnostic messages.

Various integration scenarios in CI have been worked out. Consideration of all scenarios is beyond the scope of this article and it is better to refer to the documentation. Here are just a few links so that the reader can make a general impression:

PVS-Studio analyzer effectively detects a wide range of errors, from typos to memory leaks . This is possible thanks to data flow analysis, symbolic execution, pattern matching, method annotation (including automatic). You can learn more about operating principles from the article " Technologies Used in PVS-Studio Code Analyzer for Finding Errors and Potential Vulnerabilities "

Why should you use PVS-Studio

By introducing the PVS-Studio static code analyzer into the development process, you will reduce the cost of fixing many errors. This frees up time to implement new functionality or for more thorough high-level testing.

With regular use of the analyzer, the code will gradually become better, which will facilitate its maintenance. Systematic error correction and the practice of writing high-quality code will reduce the likelihood of detecting zero-day vulnerabilities in the project. This topic is discussed in more detail in the article " How can PVS-Studio help in searching for vulnerabilities? "

Using the PVS-Studio tool is beneficial in teams of five or more people. You can get acquainted with the method of calculating the analyzer usage efficiency in the article " PVS-Studio ROI ".

For projects developed by one or two enthusiasts, the PVS-Studio analyzer will most likely be redundant. However, it can also be used in such small projects, especially since we provide several free licensing options for students, open source projects, etc.

Most often, at the beginning, our customers acquire a license for one year. After a year, when they are convinced that the capabilities of the analyzer and their support are completely satisfactory, they renew the license for two or three years at once. This allows them to get a substantial discount. You can request prices and consult on licensing issues here .

Become our customer. Using PVS-Studio, you will increase the maturity of the development process, save money in the fight against errors and create better software.

We will provide you with fast, quality support. The questions are answered directly by the programmers developing the modules on which the question arose. This helps to get answers even in difficult situations. One example of such communication is " False positives in PVS-Studio: how deep the rabbit hole is."

Objection replies

Sometimes programmers negatively perceive the idea of introducing static code analysis into the development process, criticizing the static analysis methodology as a whole or specifically the PVS-Studio tool. When the discussion begins, it turns out that the criticism is not substantiated and stems simply from an unwillingness to change something in the established development process. Consider the typical arguments for not changing anything, and what their weakness consists in.

“Static analysis will take part of the working time”

The statement “static analysis will take part of the working time” in isolation from the context is true. Regularly reviewing static analyzer warnings issued for new or changed code really takes time. However, the thought should be continued: but the time spent on this is much less than the cost of identifying errors by other methods.

Where does the opinion about the need to spend time warning static code analyzers come from?

Programmers still unfamiliar with the code analysis methodology confuse test runs and regular use. At the first starts, any analyzers give a huge list of warnings, many of which are false. The reason is that the analyzer is not yet configured. A tuned analyzer produces a small number of false positives during regular launches. In other words, with regular use, most warnings will detect real defects or an odor code. It is only important to make this setting.

This topic is described in more detail in the article “ Working with Objections: Static Analysis Will Take Part of the Working Time ”.

“The static analyzer is very noisy (it produces a lot of false positives)”

As mentioned above, this conclusion is made using an unconfigured code analyzer. After setting up PVS-Studio, you can expect that the percentage of false positives will be 10-20%. That is, with five warnings issued, four will indicate real errors or a code that is likely to cause errors in the future. An example of such a setting can be seen in the article “ PVS-Studio analyzer specifications using the EFL Core Libraries example, 10-15% of false positives ”.

Another reason that distorts the view of the analyzer is the desire to include as many warnings as possible, without understanding their purpose. For example, if you enable the MISRA rule set focused on embedded systems for a classic Windows application, the analyzer generates hundreds of thousands of warnings. There will be no practical meaning in them. Especially unnecessary diagnostics interfere at the stage of acquaintance with the tool and form a misconception about its diagnostic capabilities. The article " How to quickly see interesting warnings that the PVS-Studio analyzer for C and C ++ code gives? " Will help to avoid this.

“Introducing static analysis into the development process is very difficult, long and expensive”

Very well, these concerns are reflected in this comment:

Alas, the static analyzers themselves are nothing more than toys. Introducing them into the workflow is a hell of a job, you need to select individuals to process and filter the results. Attempts to shift these tasks to the shoulders of ordinary developers usually end in nothing.

It's not so scary. There are at least three approaches that allow you to painstakingly implement static analysis even in large old projects.

First approach. "Ratchet Method", which Ivan Ponomarev speaks well in his report " Continuous Static Code Analysis ".

Second approach. To quickly start using static analysis, we offer PVS-Studio customers to use the " markup base ". The general idea is as follows. The user started the analyzer and received many warnings. Since a project that has been developed for many years, is alive, develops and brings money, then most likely there will not be many warnings in the report indicating critical defects. In other words, critical bugs have already been fixed in one way or another in more expensive ways or thanks to feedback from customers. Accordingly, everything that the analyzer now finds can be considered a technical debt, which is impractical to try to eliminate immediately.

You can tell PVS-Studio to consider these warnings as irrelevant (postpone technical debt for later), and not show them again. The analyzer creates a special file where it stores information about so far uninteresting errors. And now PVS-Studio will issue warnings only on new or changed code. Moreover, all this is implemented cleverly. If, for example, an empty line is added to the beginning of a certain .cpp file, then the analyzer understands that, in fact, nothing has changed, and will remain silent. This markup file can be embedded in the version control system. The file is large, but it’s not scary, because often it makes no sense to lay it.

Now all programmers will see warnings related only to new or changed code. Thus, the analyzer can begin to use what is called the next day. And it will be possible to return to technical debt later, and gradually correct errors and configure the analyzer.

The third approach. You can conclude a contract with us and delegate to our team the work of setting up and integrating static analysis. An example of this practice: " How the PVS-Studio team improved the Unreal Engine code ."

“We launched the analyzer and did not find anything interesting”

This is entirely possible, but this does not mean that the analyzer will not be useful. The thing is that the errors were corrected by more expensive methods. This is how to take the text of a book, already read by several proofreaders, and see what spell checking built-in Microsoft Word can find. Little errors will be found, but it does not follow from this that the check function in Word will not be useful when writing new texts.

This topic is discussed in more detail in the article " Philosophy of Static Code Analysis: we have 100 programmers, the analyzer found few errors, is it useless? ".

“A static analyzer is expensive, it’s better to hire another programmer / tester”

In fact, this means that you do not want to change anything. Indeed, before the team grew and replenished with new programmers and testers. However, this did not lead to a significant increase in the maturity of the development process. Nonetheless, let's examine this objection in more detail.

Firstly, taking an extra person to look for errors is much more expensive than starting to use a code analyzer. Calculate a person’s salary fund for the year. Add taxes and arrangement of the workplace. The argument that a license is expensive ceases to be an argument. And still the static analyzer, unlike the person, does not go on vacation, is not sick and does not leave. If we are talking about large teams, for example, 100 people, then in order to get some effect, you will need to hire several people. The gap in favor of a static analyzer is widening.

Secondly, the greatest effect is achieved due to the synergy of using various error search techniques. Some errors are well detected by unit tests, some with manual testing, and so on. Imagine the situation. The project has 10 programmers, many unit tests are written, but there are no testers. The quality of the project does not suit users and the idea is to open a job as a tester. But this is not done under the pretext “it is better to hire another programmer”, let there be even more unit tests! Agree, this is the wrong decision. Obviously, the quality assurance process is one-sided and the addition of manual testing will bring much greater benefits. The same situation is with static analysis.

“Dynamic analysis is more efficient than static.”

Static analyzers find some errors well. Some are dynamic analyzers. These tools complement each other and it makes no sense to choose one thing.

For example, dynamic analyzers cannot find many typo errors or detect unreachable code. In the article " Validating Valgrind Dynamic Analyzer Code Using a Static Analyzer ", you may encounter some of these errors.

“Unit tests are more efficient than static code analysis”

If you choose between writing unit tests and static analysis, then perhaps the tests will be more important and useful. But no choice needs to be made. It is necessary to use both unit tests and static code analysis. These error search methodologies complement each other perfectly.

Static analysis will complement unit tests for the following reasons:

Nobody tests the tests themselves and they often contain errors. In our articles, we have provided examples of errors in unit test code many times. Accordingly, static analysis can find errors in tests, which, in turn, can find errors in the main application code.
It is very difficult to cover all the code with tests. Especially when it comes to code for handling emergency situations. Static analyzers check all code.
Some errors are impossible or extremely difficult to detect with unit tests. Example: V597 (CWE-14) .
Some errors manifest themselves only when processing large amounts of data, and it is impractical to use unit tests to simulate such situations. An example is the overflow of a 32-bit variable in a 64-bit program ( V108 , V127 ).
It’s easier and faster to find an error by running a static analysis than debugging the code when it turns out that it does not work out the unit test. Of course, unit tests will find more errors, but if some of them can be found in a cheaper way (static analysis), why not use it.
We find a huge number of errors in various projects. Many of these projects are well covered by tests, but as you can see, this does not help. So there is no reason not to start, in addition to unit tests, using static code analysis, thereby improving its quality and security.

“Modern free compilers can do the same thing as PVS-Studio”

Yes, indeed, compilers are evolving and new warnings are being implemented to help them find errors in the code. However, you should not expect too much from compilers, in comparison with professional paid solutions, such as PVS-Studio.

Advantages of PVS-Studio:

Users support.
Rich infrastructure (integration with other products).
Developed diagnostic capabilities.

The first two points are already enough to outweigh the scales in favor of PVS-Studio. However, let's talk about diagnostics. We are constantly developing an analyzer to get ahead of other tools. For example, we can find here such an interesting error " February 31. "

This is not enough to convince skeptical readers. Therefore, from time to time, we check other compilers and show that PVS-Studio is able to find errors in them:

PS

If you still doubt whether to use PVS-Studio, then look at what errors and in which projects we managed to detect .

useful links

If you want to share this article with an English-speaking audience, then please use the link to the translation: Andrey Karpov. Why You Should Choose the PVS-Studio Static Analyzer to Integrate into Your Development Process .

Reasons to introduce PVS-Studio static code analyzer into the development process