A simple error in coding does not mean a non-fearful error.

When popularizing the PVS-Studio static code analyzer, we usually write articles for programmers. However, some things programmers look one-sided. That is why there are software project managers who can manage the project development process to steer it in the right direction. I decided to write a few articles whose target audience are software project managers. These articles will help them better navigate the use of static code analysis methodology. Now we will consider the false postulate: “coding errors are insignificant.”

I recently wrote an article " An article on static code analysis for managers that should not be read by programmers ." Quite naturally, it began to leave comments about the fact that there is no use for the tool for finding simple errors. I will give one of these comments:

The reason is simple: the main bugs are in algorithms. In the work of analysts, mathematicians, directors, algorithms. And there are not so many bugs in coding.

In general, nothing new. Again, we encounter the myth that professional developers do not make simple mistakes . And even if they admit, it is not terrible: such errors are easy to find and, as a rule, they are not critical.
')
To discuss the assertion that professionals do not allow blunders, I do not see the point. This topic has already been dismantled many times by me in articles. In the end, if everything is so simple, why all these professionals have made so many mistakes in famous projects. At the moment, we have already found more than 11,000 errors in open source projects, although we never tried to identify as many errors as possible. This is just a byproduct of writing articles .

Now it is more interesting for me to discuss this topic: many programmers believe that truly serious errors can be made only with the implementation of algorithms. This is where I want to warn managers - this is not true. Any mistake can be critical. I do not deny that errors in the algorithms are extremely important, however, one should not underestimate the importance of typos and common mistakes.

Some programmers say: since the analyzer does not know how to look for errors in complex algorithms, it is not needed. Yes, the analyzer does not know how to search for complex algorithmic errors; it requires artificial intelligence, which has not yet been created. However, looking for common errors in the code is just as important and necessary as algorithmic errors.

Not to be unfounded, I offer you 3 examples.

For starters, you can recall the critical vulnerability in iOS, which appeared because of the double goto .

if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0) goto fail; if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0) goto fail; goto fail; if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0) goto fail; 

Details are provided in the Apple's SSL / TLS bug article. It does not matter that this error appeared due to a typo or an unsuccessful merge. Obviously, this is a "mechanical" error, not related to mathematics or algorithms. At the same time, a similar error is detected by the PVS-Studio analyzer.

Now let us recall the vulnerability in MySQL: Security vulnerability in MySQL / MariaDB sql / password.c .

 char foo(...) { return memcmp(...); } 

The error occurs due to the implicit type cast ( int -> char ), in which the values ​​of the high-order bits are discarded. This is again a mistake that is not related to complex algorithms and is well revealed by the PVS-Studio analyzer. Despite its simplicity, the error leads to the fact that on some platforms in 1 case out of 256, the procedure of comparing a hash with an expected value always returns the value 'true', regardless of the hash.

The third example. I participated in the development of a package of numerical modeling of gas-dynamic processes. A lot of mathematics, algorithms, etc. And, of course, there were errors and problems associated with this math. However, I remembered much more the problems that arise due to porting the code to 64-bit systems. By the way, it was then that the idea to create the Viva64 analyzer, which later evolved into PVS-Studio (the story: how the PVS-Studio project started 10 years ago ), was born.

One of the errors was due to incorrect positioning in the file using the _fseeki64 function. Having become a 64-bit simulation package, I was able to process more data and, as a result, write more data to disk. Only then, I could not read them correctly. Moreover, it cannot be said that the code was written somehow very badly. Approximately it was like this:

 unsigned long W, H, D, DensityPos; .... unsigned long offset = W * H * D * DensityPos; res = _fseeki64(f, offset * sizeof(float), SEEK_SET); 

Overflow occurs when the variables are multiplied. In defense of the programmer, it can be said that when he wrote this code, it is difficult to assume that in Win64 ( ILP32LL ) the size of the long type will remain 32-bit. This error was searched for very long. When such pseudocode is given, everything seems to be simple and clear. In practice, it was very difficult to understand why, when exceeding a certain threshold of the volume of data being processed, strange errors begin. The debugging week could easily be replaced by checking the code with PVS-Studio, which would have found the described bug in two accounts. Algorithms and mathematics when switching to a 64-bit system didn’t entail any difficulties.

As you can see, simple mistakes can lead to serious consequences. It is better to find them as much as possible using a static analyzer, rather than spending hours and days in debuggers. And even more so, it is better to find the error yourself. The worst option: it turns out that your application contains a vulnerability, but it is already installed on tens of thousands of computers.

And it is simply useful to find as many simple errors as possible with the help of tools in order to devote ourselves to the search for defects in algorithms and the creation of new functionality.

By the way, I suggest that managers reading this article use our services to verify their projects. We propose to conclude a small contract, under which we investigate the project and correct all the errors that we can find. First, it will be useful in any case, and secondly, if you like the result, it will open the way for further cooperation. If necessary, we are ready to sign the NDA. I propose to discuss the details by mail .

Additional links:

1. PVS-Studio page.
2. Myths about static analysis. Myth one - a static analyzer is a single use product .
3. Myths about static analysis. The second myth - professional developers do not make stupid mistakes .
4. Myths about static analysis. The third myth - dynamic analysis is better than static .
5. Myths about static analysis. The fourth myth - programmers want to add their own rules to the static analyzer .
6. Myths about static analysis. The fifth myth - you can create a small program to evaluate the tool .
7. In addition to the fifth myth: Why I do not like synthetic tests .

If you want to share this article with an English-speaking audience, then please use the link to the translation: Andrey Karpov. If the coding bug is banal