[Bug libstdc++/54351] ~unique_ptr() should not set stored pointer to null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54351 --- Comment #14 from TC --- Well, I would have argued that if the specification doesn't say that a function does X, then it doesn't do X. NullablePointer/CopyAssignable only means that the assignment operation must be supported. But then I realized that a literal reading of the specification would mean that the deleter must be called using a copy of the stored pointer - the return value of get() - rather than the stored pointer itself (again, hypothetically detectable using an instrumented fancy pointer-like thing). Which would be just absurd.
[Bug libstdc++/54351] ~unique_ptr() should not set stored pointer to null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54351 --- Comment #13 from Jonathan Wakely --- It isn't specified whether it is assigned to or not in the destructor, so I think it's conforming. D::pointer is required to meet the NullablePointer requirements, which includes CopyAssignable, so in the absence of any restrictions to the contrary the implementation can rely on assignment (and typically both release() and reset() will assign to the pointer, and reset() is a valid implementation of the destructor).
[Bug libstdc++/54351] ~unique_ptr() should not set stored pointer to null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54351 TC changed: What|Removed |Added CC||rs2740 at gmail dot com --- Comment #12 from TC --- ~unique_ptr()'s specification doesn't say that it assigns to the stored pointer at any time. Since unique_ptr can be used with pointer-like things whose assignment operator can have observable side effects, is doing this assignment in the destructor conforming?
[Bug libstdc++/54351] ~unique_ptr() should not set stored pointer to null
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54351 --- Comment #11 from Geoff Romer 2012-12-18 21:59:23 UTC --- >From discussion on the C++ LWG reflector, it appears that the standard's requirements on library types are intended to apply only during their lifetime, although the standard does not currently make this clear. LWG 2224 (http://cplusplus.github.com/LWG/lwg-active.html#2224) is tracking this issue, and its resolution should give a definitive answer. That being the case, the old behavior was not a bug, but conformant with the the intent of the standard (if not the precise wording). The new behavior is conformant as well, of course, so it's up to you whether to revert the changes; I just wanted to document for future reference that ~unique_ptr is in fact permitted to modify the stored pointer before invoking the deleter, so this bug report should not be an obstacle to e.g. having ~unique_ptr store a poison value in order to catch client bugs.
[Bug libstdc++/54351] ~unique_ptr() should not set stored pointer to null
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54351 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #10 from Jonathan Wakely 2012-08-26 00:31:08 UTC --- fixed for 4.7.2
[Bug libstdc++/54351] ~unique_ptr() should not set stored pointer to null
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54351 --- Comment #9 from Jonathan Wakely 2012-08-26 00:29:46 UTC --- Author: redi Date: Sun Aug 26 00:29:41 2012 New Revision: 190681 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190681 Log: 2012-08-26 Jonathan Wakely Geoff Romer PR libstdc++/54351 * include/bits/unique_ptr.h (unique_ptr::~unique_ptr): Do not use reset(). (unique_ptr::~unique_ptr()): Likewise. * testsuite/20_util/unique_ptr/54351.cc: New. * testsuite/20_util/unique_ptr/assign/48635_neg.cc: Adjust dg-error line numbers. Added: branches/gcc-4_7-branch/libstdc++-v3/testsuite/20_util/unique_ptr/54351.cc - copied, changed from r190679, branches/gcc-4_7-branch/libstdc++-v3/testsuite/20_util/unique_ptr/assign/48635_neg.cc Modified: branches/gcc-4_7-branch/libstdc++-v3/ChangeLog branches/gcc-4_7-branch/libstdc++-v3/include/bits/unique_ptr.h branches/gcc-4_7-branch/libstdc++-v3/testsuite/20_util/unique_ptr/assign/48635_neg.cc
[Bug libstdc++/54351] ~unique_ptr() should not set stored pointer to null
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54351 --- Comment #8 from Jonathan Wakely 2012-08-26 00:12:46 UTC --- Author: redi Date: Sun Aug 26 00:12:40 2012 New Revision: 190676 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190676 Log: PR libstdc++/54351 * include/bits/unique_ptr.h (unique_ptr::~unique_ptr): Do not use reset(). (unique_ptr::~unique_ptr()): Likewise. * testsuite/20_util/unique_ptr/54351.cc: New. * testsuite/20_util/unique_ptr/assign/48635_neg.cc: Adjust dg-error line numbers. Added: trunk/libstdc++-v3/testsuite/20_util/unique_ptr/54351.cc - copied, changed from r190674, trunk/libstdc++-v3/testsuite/20_util/unique_ptr/assign/48635_neg.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/unique_ptr.h trunk/libstdc++-v3/testsuite/20_util/unique_ptr/assign/48635_neg.cc
[Bug libstdc++/54351] ~unique_ptr() should not set stored pointer to null
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54351 --- Comment #7 from Geoff Romer 2012-08-22 19:49:28 UTC --- (In reply to comment #6) > (In reply to comment #5) > > Don't forget the array specialization. > > I won't :-) > > > Doesn't the first line of your new destructor shadow the __p member with a > > __p > > local variable? Why is that line needed at all? > > There is no __p member. Ah, sorry, I was evidently misreading something. I've corrected the bug description.
