You can choose a password length of not more than 50 characters. Do not forget to switch keyboard layout to the English. Do not choose a password too simple, less then 4 characters, because such a password is easy to find out. Allowed latin and !@#$%^&*()_-+=., characters

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.

It is common practice not to like Windows. But, as a rule, phrase: “I haven't read the book but still condemn it” describes this situation well. Despite the tendency of not like Windows, there are still some things that are implemented well. I’d like to tell you about one of them.

I’ll review the embedded into OS implementation of the lock-free stack and its performance comparison with the cross-platform analogues.

The implementation of non-blocking stack on the basis of a singly linked list (Interlocked Singly Linked Lists, SList), has been available in WinAPI for quite a while. Operations on such list initializing and stack primitives over it have been implemented. Without going into details of implementing the SLists, the Microsoft just say that they use some non-blocking algorithm in order to implement atomic synchronization, increase performance and get rid of lock problems.

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?

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?

I find this question pretty strange. The answer is yes, of course, and that will be so for a long time. But I'm asked this question from time to time at conferences or when communicating with developers on forums. I've decided to answer this question in the form of a brief post so that I could just refer people to it in the future.

We develop the PVS-Studio code analyzer for C/C++ software developers. People sometimes ask me why these particular languages; C/C++ is old and few developers use it, isn't it so? When I tell them this is quite a popular language and it is widely used, they look sincerely astonished.

Perhaps the reason is that the Internet is full of articles, forums and news about new languages and their capabilities. Programmers who don't work with the C/C++ language simply don't notice rare news items about it among all that stuff. It's quite natural: there's no point in advertising what has been widely known and used for a long time. As a result, they come to the conclusion that this language was abandoned long ago and now is used only to maintain some old projects.

If you sum up C, C++ and Objective-C, you'll get 37%. It's 6 times higher than PHP, for instance. The extinction of the C/C++ language family is quite out of the question.

Here's the answer to the question why it's C/C++ that we prefer to support in PVS-Studio: because these are the most popular languages nowadays. Besides, they are complex, tricky and much error-prone. It's just a paradise where static code analyzers can thrive.

Note. Don't take it as a criticism of the C or C++ language. It's just the price we have to pay for the flexibility of these language and the capability of getting fast optimized code they generate.

Once again I would like to touch upon the wrong belief that C/C++ is now used only in old projects or microcontrollers. No, many contemporary and popular applications are being written in this language. For instance, such is Chromium - you can't say it's an ancient project by any means.

To be honest, I don't know what the TPP project is intended for. As far as I understand, this is a set of tools to assist in research of proteins and their interaction in living organisms. However, that's not so much important. What is important is that their source codes are open. It means that I can check them with the PVS-Studio static analyzer. Which I'm very much fond of.
So, we have checked the Trans-Proteomic Pipeline (TPP) version 4.5.2 project. To learn more about the project, see the following links:

I'm going on to tell you about how programmers walk on thin ice without even noticing it. Let's speak on shift operators <<, >>. The working principles of the shift operators are evident and many programmers even don't know that using them according to the C/C++ standard might cause undefined or unspecified behavior.

I would like to begin this article from the fact that now it is 2012. I am saying this, because I often read the code in C++ at my work and for hobby, which was written about 10-20 years ago (and it is actual now), or the code written recently by the people who learned to program in C++ 20 years ago. And after that I got feeling that there was not any progress over the years, as well nothing was changed and developed, and the mammoths still roam on the Earth.

Introduction

The programming specific was very different 20 years ago. The memory and resources of CPU were measured by the bytes and the cycles, many things had not been invented yet, and we had to deal with that situation. But this is not an excuse today to write a code based on these prerequisites. The world is changing now. I can feel it in the water. I can feel it in the ground. We need to keep up with the progress.

Everything that I am going to write further only applies to the programming in C++ and the mainstream-compilers (gcc, Intel, and Microsoft), unfortunately, I have worked less with other programming languages and compilers, so I will not talk much about them. Also, I will only talk about the application programming for desktop OS (trends may differ in the clusters, microprocessors and system programming).