How does the program work with all these errors?

Our team checks a large number of open projects to demonstrate the capabilities of the PVS-Studio analyzer in finding errors. After our articles, the question “How does the program work with these errors?” Often sounds. I'll try to answer it.

Introduction

A couple of introductory words for readers who are not yet familiar with our tool. We are developing the PVS-Studio analyzer to find errors in the source code of applications written in C / C ++. The best way to show what he can do is to check open projects and find errors in them. We collect errors found in the database . If we find errors in our opinion that are interesting in our opinion, then we write an article. Anyone wishing to take a look at the updated list of articles .



So, reading our articles, some wonder how the program works at all. Programmers, I think this situation is not surprising. Each of them was allowed to edit the bug, which successfully lived in the code for 2 years. Therefore, the article is rather aimed at readers who have little to do with programming or programmers who are just starting their careers. However, in my opinion, serious programmers will also be able to find interesting and useful thoughts here.

The most important

Different code snippets are executed at different frequencies. Some sections of the code are executed each time the program is started, some are occasionally, there are sections that are executed extremely rarely.

')

The less often a section of code is executed, the easier it is to hide the error in it. I will try to explain this with examples.



If due to an error a large button is not drawn in the main window of the program, then this error will be immediately noticed. And most likely the programmer himself will correct the error and she will not even get to the testing department.



If the error depends on the input data, then it is already easier for her to hide. Imagine that a programmer is developing a graphics editor. He tested the application in the pictures with a resolution of 100x100 and 300x400. And although he wrote bad code, everything worked for him. Fortunately, the company has a testing department in which they noticed that the program does not work with elongated pictures with a resolution of 100x10000. Please note that the bug has lived a little longer.



More secretive mistakes for the occurrence of which requires special conditions. Our graphic editor works great with medium and large images. But let's imagine that the 1x1 image should be processed in a special way, and neither the programmer nor the testers thought to check this mode of operation. As a result, the program will drop from the user who accidentally creates a 1 pixel image. This time the error reached the user.



There are even more difficult to detect errors. For example, they can be found in code that should handle non-standard situations. An example is the inability to write a file to disk. Such an error can live for years in the program and nobody will know about it. It will be detected only when the user does not save their important data due to the fact that the hard disk run out. In fact, the program should have warned about this and offered to save the file to another location. But because of the mistake she took and fell.

Answer to the question

Most of the errors that we discover when checking open projects with PVS-Studio have no effect on the daily work of the program for thousands of users. All of them are in extremely rarely used parts of the code and therefore no one encounters these errors.



It cannot be otherwise. Take for example the Qt library. This library is debugged and tested. It uses a huge number of developers around the world. It simply can not be errors lying on the surface. Therefore, we will find in it with the help of PVS-Studio only those that rarely manifest themselves. For example, consider this function:

QV4::ReturnedValue QQuickJSContext2DPrototype::method_getImageData(....) { .... qreal x = ctx->callData->args[0].toNumber(); qreal y = ctx->callData->args[1].toNumber(); qreal w = ctx->callData->args[2].toNumber(); qreal h = ctx->callData->args[3].toNumber(); if (!qIsFinite(x) || !qIsFinite(y) || !qIsFinite(w) || !qIsFinite(w)) .... } 

The function contains an error. The value 'h' is not checked. Instead, the 'w' variable is checked twice. This is mistake? Yes, this is a mistake. But the likelihood that it will manifest itself is very small.



First, not all applications using the Qt library will call the method_getImageData () function. Most likely few people use it at all. Second, the error will only manifest itself if the last argument is incorrectly converted. All other arguments are processed correctly. Third, this last argument should be incorrectly specified. Thus, the probability that this error will manifest itself is very small.



And therefore, she lived in the Qt library code for a long time, before she was detected with PVS-Studio. By the way, if someone wants to read more about checking the library, I suggest taking a look at our article " Checking the Qt 5 Framework ".



Summarize.



Programs in the process of development and maintenance are tested by various techniques (unit tests, regression tests, manual tests, and so on). Explicit errors are quickly eliminated, as they are often encountered by both the developers themselves and the users of their product.



Therefore, when we launch the PVS-Studio analyzer on a well-known reliable project, such as Chromium, we can only find errors in it that almost never manifest themselves.



That is, there are errors. There are even a lot of them (check N1 , N2 , N3 , N4 ). But, launching Chromium, you are unlikely to encounter them. It will be necessary to make an effort and, perhaps, very large, to be able to get into the branch of the code that contains the error.

Is PVS-Studio not needed?

After reading to this place, you can hurry up and make an erroneous conclusion: “Once PVS-Studio is not needed, once there are insignificant, non-manifest errors”.



Usually, when I feel that such a conclusion can be made, I send the reader to get acquainted with the article “ Leo Tolstoy and Static Code Analysis ”. But now I will try again to formulate the answer in other words.



The fact is that our articles and one-time checks of projects have nothing in common with the use of static code analysis methodology. One-time checks advertise a product well, but no more. The real benefits of them are few. Benefit can be obtained only from the regular analysis of your project.



The worst thing you can do is to run the analyzer shortly before release. There is no proc. A huge number of errors that the analyzer could find, by this point will be corrected at the cost of sweat and blood. These are ineffective (example, how to waste 50 hours of time ). And then after sleepless nights in the debugger, rewriting with testers, the developers launch the analyzer and receive only a couple of useful messages. After all, they corrected all the worst things themselves, spending a lot of time and effort. What for? This is some kind of Epic Fail.



However, I do not exaggerate. A developer really often does not understand how to use code analyzers. Often in letters we see something like the following: “Funny stuff. We will use it before releases. ” It is sad. Therefore, I again and again bring light into the realm of dark bugs and programmers who do not want to think.



I'm not saying that the analyzer can find all the errors. He will find only a part. But he will do it right away. As soon as the programmer has finished writing the next piece of code.



The idea of ​​static analysis is that many errors and typos can be found at an early stage. Use it regularly, and you significantly reduce the time you spend on finding and fixing defects.

PVS-Studio is needed!

To finally convince you, I will give one practical example. We recently checked and corrected all errors in the Unreal Engine. Most of the errors were uncritical. It `s naturally. There would be a lot of critical errors, no one would use the Unreal Engine in their developments.



At some point, the analyzer started issuing 0 diagnostic messages. But the developers change the code and make edits. And now the analyzer has again started issuing warnings related to the fresh code. And we saw, one can say in real time, how new bugs get into the code. Perhaps in a few days they will be eliminated, but why suffer if the analyzer detects them immediately. Here is one of these errors:

 static void GetArrayOfSpeakers(....) { Speakers.Reset(); uint32 ChanCount = 0; // Build a flag field of the speaker outputs of this device for (uint32 SpeakerTypeIndex = 0; SpeakerTypeIndex < ESpeaker::SPEAKER_TYPE_COUNT, //<== ChanCount < NumChannels; ++SpeakerTypeIndex) { .... } check(ChanCount == NumChannels); } 

Instead of the operator && accidentally written a comma. It is impossible to name such a minor error. She got into the version control system and sure would be a problem. Fortunately, the PVS-Studio analyzer is on guard.



For those who wish to learn more in detail the history of our work with Epic Games, I suggest to get acquainted with the article " How the PVS-Studio team improved the Unreal Engine code ."

Conclusion

I suggest not to postpone and try our PVS-Studio code analyzer on your project. You can download it here . The interface of the analyzer is quite simple, but I suggest taking a look at the article " PVS-Studio for Visual C ++ ". You may find useful tips for using the analyzer. For example, many people do not realize how easily and quickly third-party libraries can be excluded from the analysis results.



If you are using a makefile for building or your own build system, then PVS-Studio Standalone will help you to check the project. This tool has a mechanism for tracking compiler launches.



If you are afraid of the number of warnings, then try a new message markup mode using a special database. Idea: all messages are considered not interesting and are not displayed. You only see messages related to the new code. You will quickly understand how regular code analysis is useful and convenient. Details: "How to implement static analysis in the project . "



Good luck!