[cfe-dev] Question about -Wlifetime and unique pointers

[Gábor Horváth via cfe-dev]

Hi Adrian,

The y and x in the example have different pointees: y will dangle and x
will be a null pointer. We correctly diagnose the dangling but will not
warn about the null dereference in this case. The reason is that the
current model does not account for nullable owners. This is something we
want to address in the future.

(As the analysis does not do any inter-procedural reasoning:) a slightly
different but related question is what assumptions should we have about the
non-const uses like the use_unique_ptr function in your example. Should we
assume that they invalidate the owners? Should we assume that they reset
the owners (make the nullable owners null)? Both? Neither?

Some experiments showed that the answer might depend on the codebase you
are working with, so we plan to introduce switches for all these
assumptions.

Cheers,
Gabor

On Sun, 3 Nov 2019 at 21:52, Adrian via cfe-dev <cfe-dev at lists.llvm.org>
wrote:

> Hello,
>
> I have a question about the experimental -Wlifetime flag/the Lifetime
> profile of the C++ core guidelines
> (https://github.com/isocpp/CppCoreGuidelines/blob/master/docs/Lifetime.pdf
> ).
>
> Consider the following example: https://godbolt.org/z/L1o35w
> x is a unique pointer, y = x.get()
> x is passed by non-const reference to a function, which can modify it
> (which it does).
> Dereferencing y gives a warning (3rd tab), as the compiler has
> detected the dependency of y on x, and the pointer held by x may be
> deleted after calling the function.
>
> However, dereferencing x does not give a warning (and it indeed crashes if
> run).
> It seems to me that the compiler already knows that x is invalid, as
> it knows y is invalid from x.
> Is there a fundamental reason why it doesn't give a a warning/why it's
> hard to in this case?
>
> Kind regards,
> Adrian
> _______________________________________________
> 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/20191104/cf193354/attachment.html>