To get a trial key
fill out the form below
Team License (a basic version)
Enterprise License (extended version)
* By clicking this button you agree to our Privacy Policy statement

Request our prices
New License
License Renewal
--Select currency--
* By clicking this button you agree to our Privacy Policy statement

Free PVS-Studio license for Microsoft MVP specialists
* By clicking this button you agree to our Privacy Policy statement

To get the licence for your open-source project, please fill out this form
* By clicking this button you agree to our Privacy Policy statement

I am interested to try it on the platforms:
* By clicking this button you agree to our Privacy Policy statement

Message submitted.

Your message has been sent. We will email you at

If you haven't received our response, please do the following:
check your Spam/Junk folder and click the "Not Spam" button for our message.
This way, you won't miss messages from our team in the future.

Example of how new diagnostics appear i…

Example of how new diagnostics appear in PVS-Studio

Mar 20 2021

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. Today we decided to tell the story of how it happened.


It all started with a review of the COVID-19 CovidSim Model project and an article about an uninitialized variable. The project turned out to be small and written using the modern C++ language standard. This means it can perfectly add to the base of test projects for regression testing of the PVS-Studio analyzer core.

Before supplementing the base, we find it useful to look through warnings to search out patterns of false positives and highlight them to improve the analyzer in future. This is also an additional opportunity to notice that something else is wrong. For example, a message fails to describe an error for a particular code construct.

Luckily, the developer who was assigned to add the project to the test base approached the task thoroughly and decided to look into the MISRA diagnostics section. This wasn't an indispensable step. MISRA diagnostics are generally specific. They can be safely disabled for such projects, as CovidSim.

MISRA C and MISRA C++ diagnostics are intended for developers of embedded systems, and their point is to limit the use of unsafe programming constructs. For example, it is not recommended to use the goto operator (V2502), since it provokes the creation of complex code, where it is easy to make a logical error. Read more about the philosophy of the MISRA coding standard in the article "What Is MISRA and how to Cook It".

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.

Anyway, let's get back to the topic. So, while skimming through the MISRA warnings, a colleague caught a glimpse of the V2507 warning issued for this code snippet.

if (radiusSquared > StateT[tn].maxRad2) StateT[tn].maxRad2 = radiusSquared;
  if (a->listpos < Cells[a->pcell].S)
    UpdateCell(Cells[a->pcell].susceptible, a->listpos, Cells[a->pcell].S);
    a->listpos = Cells[a->pcell].S;
    Cells[a->pcell].latent[0] = ai;

The V2507 rule forces us to wrap the bodies of conditional statements in curly braces.

At first, our meticulous colleague thought that the analyzer had failed. After all, there is a block of text in curly braces! Is this a false positive?

Let's take a closer look. The code only seems to be correct, but it is not! The curly braces are not attached to the if statement.

Let's tweak the code for clarity:

if (radiusSquared > StateT[tn].maxRad2)
  StateT[tn].maxRad2 = radiusSquared;


Agree, this is a nice bug. It will surely be one of the Top10 C++ bugs we found in 2021.

What follows from this? The MISRA standard approach works! Yes, it forces you to write curly braces everywhere. Yes, it's tedious. Though this is a reasonable price to pay for improving the reliability of embedded applications used in medical devices, automobiles, and other high-responsibility systems.

I'm glad developers who use the MISRA standard are doing fine. However, recommending that everyone use curly braces is a bad idea. With this approach it is very easy to bring the analyzer to the state where it becomes impossible to use it. There will be so many warnings that no one will care about them.

Finally we got to the idea of a new General Analysis diagnostic and the following rule.

The analyzer will issue a warning in case the following conditions are met for the if statement:

  • the entire conditional if statement is written in one line and has only a then branch;
  • the next statement after if is a compound statement, and it is on different lines with if.

We look forward to getting a decent rule that gives few false positives.

This is how this idea is now described in our task tracker. Perhaps something will be done differently in the implementation process, but it doesn't really matter at this point. The main thing is that a decent diagnostic rule will appear, which will begin to identify a new error pattern. Next, we will extend it to the C# and Java cores of the PVS-Studio analyzer.

We just looked at the unique example of how a new diagnostic rule came up, which we will implement in PVS-Studio. Kudos to the CovidSim project, the MISRA coding standard, and our colleague's observation skills.

Thank you for your attention and follow me into the world of C++ and bugs :). Twitter. Facebook.

Additional links:

Popular related articles
Static analysis as part of the development process in Unreal Engine

Date: Jun 27 2017

Author: Andrey Karpov

Unreal Engine continues to develop as new code is added and previously written code is changed. What is the inevitable consequence of ongoing development in a project? The emergence of new bugs in th…
The Evil within the Comparison Functions

Date: May 19 2017

Author: Andrey Karpov

Perhaps, readers remember my article titled "Last line effect". It describes a pattern I've once noticed: in most cases programmers make an error in the last line of similar text blocks. Now I want t…
The Last Line Effect

Date: May 31 2014

Author: Andrey Karpov

I have studied many errors caused by the use of the Copy-Paste method, and can assure you that programmers most often tend to make mistakes in the last fragment of a homogeneous code block. I have ne…
PVS-Studio ROI

Date: Jan 30 2019

Author: Andrey Karpov

Occasionally, we're asked a question, what monetary value the company will receive from using PVS-Studio. We decided to draw up a response in the form of an article and provide tables, which will sho…
Free PVS-Studio for those who develops open source projects

Date: Dec 22 2018

Author: Andrey Karpov

On the New 2019 year's eve, a PVS-Studio team decided to make a nice gift for all contributors of open-source projects hosted on GitHub, GitLab or Bitbucket. They are given free usage of PVS-Studio s…
The Ultimate Question of Programming, Refactoring, and Everything

Date: Apr 14 2016

Author: Andrey Karpov

Yes, you've guessed correctly - the answer is "42". In this article you will find 42 recommendations about coding in C++ that can help a programmer avoid a lot of errors, save time and effort. The au…
Technologies used in the PVS-Studio code analyzer for finding bugs and potential vulnerabilities

Date: Nov 21 2018

Author: Andrey Karpov

A brief description of technologies used in the PVS-Studio tool, which let us effectively detect a large number of error patterns and potential vulnerabilities. The article describes the implementati…
How PVS-Studio Proved to Be More Attentive Than Three and a Half Programmers

Date: Oct 22 2018

Author: Andrey Karpov

Just like other static analyzers, PVS-Studio often produces false positives. What you are about to read is a short story where I'll tell you how PVS-Studio proved, just one more time, to be more atte…
PVS-Studio for Java

Date: Jan 17 2019

Author: Andrey Karpov

In the seventh version of the PVS-Studio static analyzer, we added support of the Java language. It's time for a brief story of how we've started making support of the Java language, how far we've co…
Characteristics of PVS-Studio Analyzer by the Example of EFL Core Libraries, 10-15% of False Positives

Date: Jul 31 2017

Author: Andrey Karpov

After I wrote quite a big article about the analysis of the Tizen OS code, I received a large number of questions concerning the percentage of false positives and the density of errors (how many erro…

Comments (0)

Next comments
This website uses cookies and other technology to provide you a more personalized experience. By continuing the view of our web-pages you accept the terms of using these files. If you don't want your personal data to be processed, please, leave this site.
Learn More →