[analyzer] Should analyzer report about potential null-dereferencing?

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

[analyzer] Should analyzer report about potential null-dereferencing?

Fangrui Song via cfe-dev

Next code generates a sink node and a bug report:


int setPtr(const int&);
int* getPtr();
void f(bool is, const int x, const int y)
{
  const int *ptr = &x;
  if (is) {
    ptr = nullptr;​
  }
  setPtr(*ptr);
}


But next code just generates a sink node without a bug report:


int setPtr(const int&);
int* getPtr();
void f(bool is, const int x, const int y)
{
  const int *ptr = &x;
  if (is) {
    ptr = getPtr();​
  }
  setPtr(*ptr);
}


Why does analyzer act like that? Is there any command line option to turn this on?


Denys Petrov
Senior С++ Developer | Kharkiv, Ukraine


_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [analyzer] Should analyzer report about potential null-dereferencing?

Fangrui Song via cfe-dev
Why would the analyzer report potential null in the second example? I
honestly don't see anything wrong with this code. There's no indication
anywhere that the pointer may be null.

Sink node simply indicates that the execution path is impossible. In
this case it indicates that after the analyzer admits that the pointer
was dereferenced (in order to proceed with the analysis), it must also
admit that the pointer wasn't null to begin with. It's not absolutely
necessary to generate an explicit sink node in this case but there's not
much harm in that either.

On 4/16/20 5:28 PM, Denis Petrov via cfe-dev wrote:

>
> Next code generates a sink node and a bug report:
>
>
> int setPtr(const int&);
> int* getPtr();
> void f(bool is, const int x, const int y)
> {
>   const int *ptr = &x;
>   if (is) {
>     ptr = *nullptr*;​
>   }
>   setPtr(*ptr);
> }
>
>
> But next code just generates a sink node *without *a bug report:​
>
>
> int setPtr(const int&);
> int* getPtr();
> void f(bool is, const int x, const int y)
> {
>   const int *ptr = &x;
>   if (is) {
>     ptr = *getPtr**()*;​
> }
>   setPtr(*ptr);
> }
>
>
> Why does analyzer act like that? Is there any command line option to
> turn this on?
>
> ------------------------------------------------------------------------
> *Denys Petrov*
> Senior С++ Developer | Kharkiv, Ukraine
>
>
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [analyzer] Should analyzer report about potential null-dereferencing?

Fangrui Song via cfe-dev
Artem, thank you for clarification.

So, the answer is - Analyzer should not report about potential null-dereferencing, only just about explicit ones.

________________________________
Denys Petrov
Senior С++ Developer | Kharkiv, Ukraine
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [analyzer] Should analyzer report about potential null-dereferencing?

Fangrui Song via cfe-dev
In reply to this post by Fangrui Song via cfe-dev
Artem, ok. Thank you for clarification.

So the answer is that analyzer should not  report about potential null-dereferencing.

P.S. Something strange happened to my previous letter. Sorry for bothering.

________________________________
Denys Petrov
Senior С++ Developer | Kharkiv, Ukraine


_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev