One of the main problems with C++ is having a huge number of constructions whose behavior is undefined, or is just unexpected for a programmer. We often come across them when using our static analyzer on various projects. But, as we all know, the best thing is to detect errors at the compilation stage. Let's see which techniques in modern C++ help writing not only simple and clear code, but make it safer and more reliable.
What is Modern C++?

The term Modern C++ became very popular after the release of C++11. What does it mean? First of all, Modern C++ is a set of patterns and idioms that are designed to eliminate the downsides of good old "C with classes", that so many C++ programmers are used to, especially if they started programming in C. C++11 looks way more concise and understandable, which is very important.


What do people usually think of when they speak about Modern C++? Parallelism, compile-time calculation, RAII, lambdas, ranges, concepts, modules, and other equally important components of the standard library (for example, an API to work with the file system). These are all very cool modernizations, and we are looking forward to seeing them in the next set of standards. However, I would like to draw attention to the way the new standards allow writing more secure code. When developing a static analyzer, we see a great number of varying errors, and sometimes we cannot help thinking: "But in modern C++ this could have been avoided". Therefore, I suggest we examine several errors that were found by PVS-Studio in various Open Source projects. Also, we'll see how they can be fixed.

More read here:
Kate Milovidova 15 september 2016, 11:44

Nowadays a lot of projects are opening their source code and letting those who are interested in the development of it edit the code. OpenJDK is no exception, programmers PVS-Studio have found a lot of interesting errors that are worth paying attention to.

OpenJDK (Open Java Development Kit) - a project for the creation and implementation of Java (Java SE) platform, which is now free and open source. The project was started in 2006, by the Sun company. The project uses multiple languages- C, C++, and Java. We are interested in the source code written in C and C++. Let's take the 9th version of OpenJDK. The code of this implementation of Java platform is available at the Mercurial repository.

During verification, the analyzer found different errors in the project including: copy-paste, bugs in the operation precedence, errors in logical expressions and in pointer handling and other bugs, which are described in detail in this article.

It's always amusing to check a project which is used and maintained by a large number of people. The better and more accurate the code is, the more safely and effectively the program will work. Those bugs we found, are another proof of the usefulness of an analyzer, as it allows the detection of such errors which would otherwise be hard to detect doing simple code review.
Kate Milovidova 17 june 2016, 9:00

Here is a small e-Book for your attention: The Ultimate Question of Programming, Refactoring, and Everything. This book is intended for C/C++ programmers, but it could be of interest for developers using other languages as well.

What makes the book peculiar is the descriptions of real, not theoretical cases at the base of it. Each chapter starts with a code fragment taken from a real application, and then the author gives various tips of how this bug could be avoided. The questions touched upon in this book can help the readers improve the personal coding style and the coding standards used in the team.

The book covers 42 topics. In spite of the simple titles of the chapters, the bugs found are really various and non-standard. In addition to that, the text provides a lot of links to interesting materials that give more details on topics. To make more use of this book, please don’t hurry and go to the links provided.

1. Don't do the compiler's job
2. Larger than 0 does not mean 1
3. Copy once, check twice
4. Beware of the ?: operator and enclose it in parentheses
5. Use available tools to analyze your code
6. Check all the fragments where a pointer is explicitly cast to integer types
7. Do not call the alloca() function inside loops
8. Remember that an exception in the destructor is dangerous.
9. Use the '\0' literal for the terminal null character
10. Avoid using multiple small #ifdef blocks
11. Don't try to squeeze as many operations as possible in one line
12. When using Copy-Paste, be especially careful with the last lines
13. Table-style formatting
14. A good compiler and coding style aren't always enough
15. Start using enum class in your code, if possible
16. "Look what I can do!" - Unacceptable in programming
17. Use dedicated functions to clear private data
18. The knowledge you have, working with one language isn't always applicable to another language
19. How to properly call one constructor from another
20. The End-of-file (EOF) check may not be enough
21. Check that the end-of-file character is reached correctly (EOF)
22. Do not use #pragma warning(default:X)
23. Evaluate the string literal length automatically
24. Override and final identifiers should become your new friends.
25. Do not compare 'this' to nullptr anymore
26. Insidious VARIANT_BOOL
27. Guileful BSTR strings
28. Avoid using a macro if you can use a simple function
29. Use a prefix increment operator (++i) in iterators instead of a postfix (i++) operator
30. Visual C++ and wprintf() function
31. In C and C++ arrays are not passed by value
32. Dangerous printf
33. Never dereference null pointers
34. Undefined behavior is closer than you think
35. Adding a new constant to enum don't forget to correct switch operators
36. If something strange is happening to your PC, check its memory.
37. Beware of the 'continue' operator inside do {...} while (...)
38. Use nullptr instead of NULL from now on
39. Why incorrect code works
40. Start using static code analysis
41. Avoid adding a new library to the project.
42. Don't use function names with "empty"

For those, who find reading PDF format more convenient:
Kate Milovidova 11 may 2016, 6:52

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.
Andrey2008 21 november 2014, 14:24

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.

Andrey2008 18 september 2014, 16:15

OutsourcingAs 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.
We have successfully solved both tasks. But this article is not about the outsourcing business; it is about our experience. We don't mean the organizational experience - there are plenty of articles about that. We mean the experience of working with the code of third-party projects. This is what we want to tell you about.
Andrey2008 23 june 2014, 6:52

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.
Andrey2008 9 april 2014, 11:46

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?

Andrey2008 3 april 2014, 10:29

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.
Andrey2008 25 march 2014, 6:40

Boost, PVS-Studio

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?

Andrey2008 23 march 2014, 8:30
1 2