Proposed resolution:

This wording is relative to N4296.

1. Change [util.smartptr.shared.const] p29 as indicated:

   template <class Y, class D> shared_ptr(unique_ptr<Y, D>&& r);
   

   […]

   -29- Effects: If r.get() == nullptr, equivalent to shared_ptr(). Otherwise, if D is not a reference type, equivalent to shared_ptr(r.release(), r.get_deleter()). Otherwise, equivalent to shared_ptr(r.release(), ref(r.get_deleter()))Equivalent to shared_ptr(r.release(), r.get_deleter()) when D is not a reference type, otherwise shared_ptr(r.release(), ref(r.get_deleter())).

[ 2015-01-18 Library reflector vote ]

The issue has been identified as Tentatively Ready based on eight votes in favour.

unique_ptr guarantees that it will not invoke its deleter if it stores a null pointer, which is useful for deleters that must not be called with a null pointer e.g.

unique_ptr<FILE, int(*)(FILE*)> fptr(file, &::fclose);

However, shared_ptr does invoke the deleter if it owns a null pointer, which is a silent change in behaviour when transferring ownership from unique_ptr to shared_ptr. That means the following leads to undefined behaviour:

std:shared_ptr<FILE> fp = std::move(fptr);

Peter Dimov's suggested fix is to construct an empty shared_ptr from a unique_ptr that contains a null pointer.