[PATCH] D13080: [libc++] ~unique_ptr() should not set stored pointer to null

[David Blaikie via cfe-commits]

On Tue, Sep 22, 2015 at 5:26 PM, Daniel Cheng via cfe-commits <
cfe-commits at lists.llvm.org> wrote:

> dcheng added a comment.
>
> In http://reviews.llvm.org/D13080#251324, @dblaikie wrote:
>
> > I'd still be curious to see a stronger justification from the standard
> >  about this.
> >
> > I know you mentioned/quoted the definition of ~unique_ptr in the
> standard -
> >  but I'm not sure that is meant to imply observable behavior during
> >  destruction (though I could be wrong). Is there anything in the standard
> >  about accessing objects while their dtors are executing?
>
>
> From 3.8.5 [basic.life]:
> Before the lifetime of an object has started but after the storage which
> the object will occupy has been
> allocated or, after the lifetime of an object has ended and before the
> storage which the object occupied is
> reused or released, any pointer that refers to the storage location where
> the object will be or was located
> may be used but only in limited ways. For an object under construction or
> destruction, see 12.7.
>
> From 12.7.1 [class.dtor]:
> For an object with a non-trivial destructor, referring to any non-static
> member or base class of the object after the destructor finishes execution
> results in undefined behavior.
>
> So I believe the standard permits object access while the dtor is still
> executing.
>

Thanks for the wording - seems plausible.

My other hesitation here is: if the object being destroyed needs to use
itself through the pointer in the unique_ptr, isn't it already
fragile/broken? If the unique_ptr was reset or set to null, etc, before
destruction happened it would fail in the same way it is failing now? So
it's not safe to be held by a unique_ptr, really...


>
>
> http://reviews.llvm.org/D13080
>
>
>
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20150922/c17935c4/attachment-0001.html>