http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54351
Bug #: 54351 Summary: ~unique_ptr() should not set __p to null Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: gro...@google.com libstdc++'s unique_ptr destructor is currently implemented as: ~unique_ptr() noexcept { reset(); } This has the effect of resetting the stored pointer to null, and then invoking the deleter on the formerly-stored pointer. I believe this is inconsistent with the language standard, which specifies the destructor as "If get() == nullptr there are no effects. Otherwise get_deleter()(get())." (note no mention of any side effects on the value of the stored pointer). This is a problem because this implementation will break code that (legitimately, AFAICT) relies on being able to continue to invoke operations on the scoped_ptr while the destructor is executing. The fix is to reimplement the destructor (in both the base template and the array specialization) as ~unique_ptr() noexcept { if (__p != pointer()) get_deleter()(__p); } If the intent is to zero out __p to help catch use-after-destruction errors, I believe it would be permissible to set __p to null after the call to get_deleter(), because at that point the change would no longer be visible to conforming code. To make this concrete, here's an example: the following program prints "bad" under libstdc++, but I believe a standard-conforming implementation is required to print "good": ============================= #include <iostream> #include <memory> using std::cout; using std::endl; using std::unique_ptr; struct A; struct B { unique_ptr<A> a; }; struct A { B* b; ~A() { if (b->a == nullptr) { cout << "bad" << endl; } else { cout << "good" << endl; } } }; int main(int argc, char** argv) { B b; b.a.reset(new A); b.a->b = &b; } =============================== As a point of comparison, MSVC++ 2010 prints "good" on this example program.