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

[Deep Majumder via cfe-dev]

The second one seems about right to me. The first one is a bit perplexing.
In fact, if p were a unique_ptr, the first one would have emitted a warning
on *p.
Warm regards,
Deep

On Mon, 20 Sep, 2021, 6:03 pm via cfe-dev, <cfe-dev at lists.llvm.org> 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?
>
>
>
> ----
>
>
>
> By returning a null pointer from a function it suddenly we no longer
> report an error:
>
>
>
>   int *get() { return 0; }
>
>   void foo() {
>
>     int *p = get();
>
>     *p = 42; // no warning?
>
>   }
>
>
>
> According to my investigation the bug actually found and a sink node will
> be generated in the Exploded graph, but the bug report will be marked as
> invalid by the ReturnVisitor.
>
> This behavior could be altered to prevent such suppression from happening
> by setting the `suppress-null-return-paths` analyzer option to `true`.
>
>
>
> Am I right that this is the intentional behavior and if we want to catch
> bugs like this, then we should enable the aforementioned option?
>
>
>
> /CC NoQ
>
>
>
> Regards,
>
> Balazs
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20210920/59650f3d/attachment.html>