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--
USD
EUR
GBP
RUB
* 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.

>
>
>
Explanation on Diagnostic V595

Explanation on Diagnostic V595

Oct 26 2015
Author:

Among others, PVS-Studio has diagnostic V595 "The pointer was utilized before it was verified against nullptr". I get lots of questions from our users regarding this diagnostic, so I decided to prepare a detailed answer in advance to help explain the principle behind it to future users.

See the description of diagnostic V595 in the documentation: The pointer was utilized before it was verified against nullptr.

A typical question regarding V595 sounds like this:

I have the following code:

void MyClass::Do()
{
  m_ptr->Foo(1, 2, 3);
  Process(1, 2, 3, 4, 5);
}

The 'm_ptr' member can sometimes get zero values. When it happens, the program crashes. I expected the PVS-Studio analyzer to warn me that the 'm_ptr' pointer should have been checked before use. I want to get the V595 warning but it's not displayed. Please explain why.

I'll try to give a detailed answer.

In general, the PVS-Studio analyzer cannot diagnose issues when a pointer can be null and must be checked before use.

If we made a "straightforward" diagnostic to warn you whenever a pointer is used without a check, it wouldn't do any good because you'd be getting such a huge amount of false positives that a real bug, if any, would get lost among false positives and never be discovered. That's why it wouldn't make sense doing it that way.

Ideally, we should try to figure out if the pointer can be null. But it's an incredibly difficult task. We'd need to analyze the call graph and find out what values the variables can have. It's just impossible in practice. Different analyzers, including PVS-Studio, try to partly solve this task for simple cases, but in general they are far from success. Many bugs would stay unnoticed by user; many others would be missed by the analyzer.

The PVS-Studio analyzer can find that kind of bug only in simple cases, for example:

void Foo(int *p)
{
  if (!p)
  {
    p[1] = 2; //V522
  }
}

It detects that the program enters the if-statement's body if the pointer equals 0; therefore, dereferencing it will cause an error. But it's a very simple example. In complex ones, like that discussed in the beginning, the analyzer is just helpless. It can't figure out what is currently stored in 'm_ptr'.

Since the analyzer is obviously bad at solving tasks like that in a straightforward fashion, we use some roundabout ways to look for errors of this type. One of these ways is to use the V595 diagnostic. The idea behind it is: output a warning when a pointer is first used and then checked.

Here's an example. PVS-Studio doesn't know the contents of 'p', so it keeps silent:

void Foo()
{
  int *p = Get();
  p[0] = 1;
  ....
}

But at some point later, the programmer recalled that the pointer could be equal to null and implemented a check for it:

void Foo()
{
  int *p = Get();
  p[0] = 1; // V595
  ....
  if (p == NULL)
    Zzz();
}

Here's when PVS-Studio outputs the V595 warning. It can't evaluate the Get() function's return result, but it doesn't actually need that. It just "sees" that the pointer is checked for being null a bit later in the code, and infers from it that this pointer can be null on certain occasions and can't be dereferenced without being checked first.

Hopefully I have managed to clarify on how the analyzer handles this kind of bugs and why it doesn't display the warning for the code sample discussed in the beginning. There is no check of the 'm_ptr' variable for 0 later in the code, so there is no warning. The analyzer is helpless here, unfortunately.

Popular related articles
Appreciate Static Code Analysis!

Date: Oct 16 2017

Author: Andrey Karpov

I am really astonished by the capabilities of static code analysis even though I am one of the developers of PVS-Studio analyzer myself. The tool surprised me the other day as it turned out to be sma…
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…
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…
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…
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 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…
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…
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…
The way static analyzers fight against false positives, and why they do it

Date: Mar 20 2017

Author: Andrey Karpov

In my previous article I wrote that I don't like the approach of evaluating the efficiency of static analyzers with the help of synthetic tests. In that article, I give the example of a code fragment…
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…

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 →
Accept