Proposed resolution:

Resolved by acceptance of N4190.

[ 2016-08 - Chicago ]

Thurs AM: Moved to Tentatively Resolved

[ 2016-08-03, Alisdair Meredith comments ]

As C++17 removes auto_ptr, I suggest closing this issue as closed by paper N4190.

Previous resolution [SUPERSEDED]:

This wording is relative to ISO/IEC 14882:2014(E).

1. Change [auto.ptr.conv] as indicated:

   template<class Y> operator auto_ptr_ref<Y>() throw();
   

   -?- Requires: X* can be implicitly converted to Y*.

   -3- Returns: An auto_ptr_ref<Y> that holds *this.

   -?- Notes: Because auto_ptr_ref is present for exposition only, the only way to invoke this function is by calling one of the auto_ptr conversions which take an auto_ptr_ref as an argument. Since all such conversions will call release() on *this (in the form of the auto_ptr that the auto_ptr_ref holds a reference to), an implementation of this function may cause instantiation of said release() function without changing the semantics of the program.

   template<class Y> operator auto_ptr<Y>() throw();
   

   -?- Requires: X* can be implicitly converted to Y*.

   -4- Effects: Calls release().

   -5- Returns: An auto_ptr<Y> that holds the pointer returned from release().

[ 2016-03-16, Alisdair Meredith comments ]

This issue is a defect in a component we have actively removed from the standard. I can't think of a clearer example of something that is no longer a defect!

[ 2015-07, Telecon ]

Marshall to resolve.

In C++14 sub-clause [auto.ptr.conv], there appears to be no requirement that the formation of an auto_ptr_ref<Y> from an auto_ptr<X> is done only when X* can be implicitly converted to Y*.

For example, I expect formation of the auto_ptr_ref<A> from the prvalue of type auto_ptr<B> to be invalid in the case below (but the wording does not seem to be there):

#include <memory>

struct A { };
struct B { } b;

std::auto_ptr<B> apB() { return std::auto_ptr<B>(&b); }
int main() {
  std::auto_ptr<A> apA(apB());
  apA.release();
}

The behaviour of the implementation in question on the case presented above is to compile and execute it successfully (which is what the C++14 wording implies). The returned value from apA.release() is essentially reinterpret_cast<A*>(&b).

There is nothing in the specification of

template <class X>
template <class Y> operator auto_ptr<X>::auto_ptr_ref<Y>() throw();

which implies that X* should be implicitly convertible to Y*.

The implementation in question uses the reinterpret_cast interpretation even when Y is an accessible, unambiguous base class of X; the result thereof is that no offset adjustment is performed.