bugs

Example of How New Diagnostics Appear in PVS-Studio

Users sometimes ask how new diagnostics appear in the PVS-Studio static analyzer. We answer that we draw inspiration from a variety of sources: books, coding standards, our own mistakes, our users' emails, and others. Recently we came up with an interesting idea of a new diagnostic.

Example of How New Diagnostics Appear in PVS-Studio

by Andrey Karpov

From the article:

As for application software development, it doesn't make sense to enable them. The CovidSim project could do without them. Otherwise, a user will simply drown in a huge number of messages that are of little use in this case. For example, when experimenting with this set of diagnostics, we received more than a million warnings for some medium-sized open projects. Roughly speaking, every third line of code might be faulty in the view of MISRA. No one will scrape through all warnings, much less fix them. The project is either developed immediately taking into account MISRA recommendations, or this coding standard is irrelevant for it.
 

Why PVS-Studio Uses Data Flow Analysis: Based on Gripping Error in Open Asset Import Library

An essential part of any modern static code analyzer is data flow analysis. However, from an outside perspective, the use of data flow analysis and its benefit is unclear.

Why PVS-Studio Uses Data Flow Analysis: Based on Gripping Error in Open Asset Import Library

by Andrey Karpov

From the article:

It all started with checking the latest version of the Qt 6 library. There was a separate usual article on this, where I'd described 77 errors found. It turned out that at first, I decided to flip through the report, not excluding the third-party libraries' warnings. In other words, I didn't exclude the warnings related to \src\3rdparty in the settings. It so happened that I immediately ran up against a gripping error example in the Open Asset Import Library. So, I decided to write this extra little note about it.

Why PVS-Studio Doesn't Offer Automatic Fixes

Static analyzer PVS-Studio can detect bugs in pretty complex and intricate parts of code, and coming up with appropriate fixes for such bugs may be a tough task even for human developers. That's exactly the reason why we should avoid offering any options for automatic fixing at all. Here are a couple of examples.

Why PVS-Studio Doesn't Offer Automatic Fixes

by Andrey Karpov

From the article:

But it only simplifies the code, not fixes it! Somebody else noticed this and opened a discussion: os_thread_windows.c - get_rel_wait() will block if abstime is in the past. As you can see, even humans make mistakes when trying to come up with a fix. Machines are just hopeless in that respect.

Checking Clang 11 with PVS-Studio

It's no secret that compilers employ their own built-in static code analyzers, and those are developing as well. That's why we write articles every now and then to show that our static analyzer, PVS-Studio, can find bugs even inside compilers and that we are worth our salt.

Checking Clang 11 with PVS-Studio

by Andrey Karpov

From the article:

The programmer is using a modulo operation to get a random value of either 0 or 1. But the value 1 seems to confuse developers and make them write the classic anti-pattern in which the modulo operation is performed on 1 instead of 2. The X % 1 operation is meaningless as it always evaluates to 0.

A Note of Caution about Using PVS-Studio on godbolt.org (Compiler Explorer)

We have added an option allowing you to experiment with the PVS-Studio static analyzer on the godbolt.org (Compiler Explorer) website. It supports analysis of C and C++ code.

A Note of Caution about Using PVS-Studio on godbolt.org (Compiler Explorer)

by Andrey Karpov

From the article:

This may be promising from the perspective of satisfying one's curiosity, writing articles, and so on. But there's a downside to it too: rather than using synthetic examples to explore or try out the tool, people may start relying on them to evaluate and compare it against other analyzers. And this is a very bad approach because the results will be unreliable and dependent on how the test examples are written.

Zero, one, two, Freddy's coming for you

The article might be of interest for authors of books, articles, and C++ coding standards. Based on the given material, you can discuss questions of C++ code quality and ways how to reduce the likelihood of errors' occurence.

Zero, one, two, Freddy's coming for you

by Andrey Karpov

From the article:

This post continues the series of articles, which can well be called «horrors for developers». This time it will also touch upon a typical pattern of typos related to the usage of numbers 0, 1, 2. The language you're writing in doesn't really matter: it can be C, C++, C#, or Java. If you're using constants 0, 1, 2 or variables' names contain these numbers, most likely, Freddie will come to visit you at night. Go on, read and don't say we didn't warn you.

 

Top 10 Bugs Found in C++ Projects in 2019

Another year is drawing to an end, and it's a perfect time to make yourself a cup of coffee and reread the reviews of bugs collected across open-source projects over this year.

Top 10 Bugs Found in C++ Projects in 2019

by Maxim Zvyagintsev

From the article:

float yScale = 1.0 / tan((3.141592538 / 180.0) * fov / 2);

There's a tiny typo in the Pi number (3,141592653...): the number "6" is missing at the 7th decimal place.
 

Macro Evil in C++ Code

The C++ language opens extensive opportunities to go without macros. So let’s try to use macros as seldom as possible!

Macro Evil in C++ Code

by Andrey Karpov

From the article:

The ATL library provides such macros, as A2W, T2W and so on for string conversion. However, few people know that it is very dangerous to use these macros inside loops. Within the macro, a call to the alloca function occurs, which will repeatedly allocate memory on each loop iteration on the stack. A program makes show that it works correctly. Once a program starts to handle longer strings and the number of loop iterations increases, the stack can just end at the most unexpected moment.

Technologies used in the PVS-Studio code analyzer for finding bugs and potential vulnerabilities

The PVS-Studio analyzer is gradually becoming more complicated but these changes can be hardly described in a Release-history. For example, this year we have consistently implemented symbolic computations in the analyzer. This is why it was agreed to write a note on algorithms and technologies, which PVS-Studio now uses to search for errors and potential vulnerabilities.

Technologies used in the PVS-Studio code analyzer for finding bugs and potential vulnerabilities

by Andrey Karpov

From the article:

Here a mixture of technologies is working: data flow analysis, symbolic execution, and automatic method annotation (we will cover this technology in the next section). The analyzer sees that X variable is used in the Div function as a divisor. On this basis, a special annotation is built for the Div function. Further it is taken into account that in the function a range of values [0..4] is passed as the X argument. The analyzer comes to a conclusion that a division by 0 has to occur.