[cfe-dev] [analyzer] Questions about the null dereference checker

[via cfe-dev]

Thanks Harald,

I missed that.

 

On the other hand, I still think that we should be consistent. (Hereby thanks for Deep for the unique_ptr case.)

And, by definition we dereferenced a null pointer, so the abstract machine should halt.

That being said, a slightly modified version of the same code:

https://godbolt.org/z/Eenavva8x

 

constexpr void foo() {

  int *p = 0;

  *p = 44;

}

 

This code won’t compile, and reports an error:

error: constexpr function never produces a constant expression [-Winvalid-constexpr]

note: assignment to dereferenced null pointer is not allowed in a constant expression

 

So, in this sense, the abstract machine (aka. the analyzer) should recognize this null dereference IMO.

That way it would be consistent with the users expectation, also with the store (lvalue) case and with the unique_ptr case.

 

Balazs

 

From: Harald van Dijk <harald at gigawatt.nl> 
Sent: 2021. szeptember 20., hétfő 14:53
To: benicsbalazs at gmail.com; cfe-dev at lists.llvm.org
Subject: Re: [cfe-dev] [analyzer] Questions about the null dereference checker

 

Hi,

On 20/09/2021 13:33, via cfe-dev wrote:

Hi,

Let’s examine this code snippet:

 

  void simply_deref_null() {

    int *p = 0;

    *p ; // no warning?

    *p = 42; // warns!

  }

 

Turns out the NullDereference checker treats the two pointer derefs differently.

For simply reading through a null pointer is allowed but storing a value is prohibited.

 

Why don't we prohibit reading through null pointers?

Reads through null pointers do trigger the warning as well. However, there is no read through a null pointer here. Dereferencing a pointer produces an lvalue, not an rvalue, and discarding an lvalue expression does not cause a load.

If you change the example to, for example,

int simply_deref_null() {
  int *p = 0;
  return *p;
}

you will see:

test.cc:3:10: warning: Dereference of null pointer (loaded from variable 'p') [core.NullDereference]
  return *p;
         ^~

Cheers,
Harald van Dijk

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20210920/1dc5ff0b/attachment.html>