CppCat is a static code analyzer integrating into the Visual Studio 2010-2013 environment. The analyzer is designed for regular use and allows detecting a large number of various errors and typos in programs written in C and C++. For the purpose of popularizing it, we've decided to launch a student-support program granting free licenses to every higher school student who will contact and ask us about that. You just need to send us a photo of your student card or transcript.
The authors of the PVS-Studio analyzer invite you to test your attentiveness.
Code analyzers never get tired and can find errors a human's eye cannot easily notice. We have picked a few code fragments with errors revealed by PVS-Studio, all the fragments taken from well-known open-source projects.
We invite you to take part in a competition against code analyzers to test your agility by trying to find the errors by yourself. You will be offered 15 randomly selected tasks. Every correct answer earns you one score if you give it within 60 seconds. The code fragments are short and 60 seconds is a fair limit.
Let's examine a couple of examples with errors for you to understand how to give the answer.
As you know, our main activity is development of the code analyzers PVS-Studio and CppCat. Although we have been doing this for a long time now and - as we believe - quite successfully, an unusual idea struck us recently. You see, we do not use our own tools in exactly the same way our customers do. Well, we analyze the code of PVS-Studio by PVS-Studio of course, but, honestly, the PVS-Studio project is far from large. Also, the manner of working with PVS-Studio's code is different from that of working with Chromium's or LLVM's code, for example.
We felt like putting ourselves in our customers' shoes to see how our tool is used in long-term projects. You see, project checks we regularly do and report about in our numerous articles are done just the way we would never want our analyzer to be used. Running the tool on a project once, fixing a bunch of bugs, and repeating it all again just one year later is totally incorrect. The routine of coding implies that the analyzer ought to be used regularly - daily.
OK, what's the purpose of all that talk? Our theoretical wishes about trying ourselves in third-party projects have coincided with practical opportunities we started to be offered not so long ago. Last year we decided to allocate a separate team in our company to take up - ugh! - outsourcing; that is, take part in third-party projects as a developer team. Moreover, we were interested in long-term and rather large projects, i.e. requiring not less than 2-3 developers and not less than 6 months of development. We had two goals to accomplish:
- try an alternative kind of business (custom development as opposed to own product development);
- see with our own eyes how PVS-Studio is used in long-term projects.
I have studied numbers of errors caused by using the Copy-Pate method and can assure you that programmers most often tend to make mistakes in the last fragment of a homogeneous code block. I have never seen this phenomenon described in books on programming, so I decided to write about it myself. I called it the "last line effect".
Just recently I've checked the VirtualDub project with PVS-Studio. This was a random choice. You see, I believe that it is very important to regularly check and re-check various projects to show users that the PVS-Studio analyzer is evolving, and which project you run it on doesn't matter that much - bugs can be found everywhere. We already checked the VirtualDub project in 2011, but we found almost nothing of interest then. So, I decided to take a look at it now, 2 years later.
I downloaded the archive VirtualDub-1.10.3-src.7z from the VirtualDub website. Analysis was performed by PVS-Studio 5.10. It took me just about one hour, so don't be strict with me. I surely must have missed something or, on the contrary, taken correct code fragments for incorrect ones. If you develop and maintain the VirtualDub project, please don't rely on my report - check it yourselves. We always help the open-source community and will grant you a registration key.
I'm also asking Avery Lee to get me right. Last time his reaction to my mentioning VirtualDub in one of the articles was pretty negative. I never mean to say about any program that it's buggy. Software errors can be found in every program. My goal is to show how useful the static code analysis technology can be. At the same time, it will help to make open-source projects a bit more reliable. And that's wonderful.
In this article I'm going to discuss a problem few people think of. Computer simulation of various processes becomes more and more widespread. This technology is wonderful because it allows us to save time and materials which would be otherwise spent on senseless chemical, biological, physical and other kinds of experiments. A computer simulation model of a wing section flow may help significantly reduce the number of prototypes to be tested in a real wind tunnel. Numerical experiments are given more and more trust nowadays. However, dazzled by the triumph of computer simulation, nobody notices the problem of software complexity growth behind it. People treat computer and computer programs just as a means to obtain necessary results. I'm worried that very few know and care about the fact that software size growth leads to a non-linear growth of the number of software bugs. It's dangerous to exploit a computer treating it just as a big calculator. So, that's what I think - I need to share this idea with other people.
I'm currently experiencing a strong cognitive dissonance, and it won't let me go. You see, I visit various programmers' forums and see topics where people discuss noble ideas about how to write super-reliable classes; somebody tells he has his project built with the switches -Wall -Wextra -pedantic -Weffc++, and so on. But, God, where are all these scientific and technological achievements? Why do I come across most silly mistakes again and again? Perhaps something is wrong with me?
Not so long ago one of our colleagues left the team and joined one company developing software for embedded systems. There is nothing extraordinary about it: in every firm people come and go, all the time. Their choice is determined by bonuses offered, the convenience aspect, and personal preferences. What we find interesting is quite another thing. Our ex-colleague is sincerely worried about the quality of the code he deals with in his new job. And that has resulted in us writing a joint article. You see, once you have figured out what static analysis is all about, you just don't feel like settling for "simply programming".
Some of our users run static analysis only occasionally. They find new errors in their code and, feeling glad about this, willingly renew PVS-Studio licenses. I should feel glad too, shouldn't I? But I feel sad - because you get only 10-20% of the tool's efficiency when using it in such a way, while you could obtain at least 80-90% if you used it otherwise. In this post I will tell you about the most common mistake among users of static code analysis tools.
We thought of checking the Boost library long ago but were not sure if we would collect enough results to write an article. However, the wish remained. We tried to do that twice but gave up each time because we didn't know how to replace a compiler call with a PVS-Studio.exe call. Now we've got us new arms, and the third attempt has been successful. So, are there any bugs to be found in Boost?