[Bug libstdc++/51609] New: [C++11] unique_ptr<const T[]>::reset rejects cv-compatible argument pointers

[Bug libstdc++/51609] New: [C++11] unique_ptr<const T[]>::reset rejects cv-compatible argument pointers

[daniel.kruegler at googlemail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51609

             Bug #: 51609
           Summary: [C++11] unique_ptr<const T[]>::reset rejects
                    cv-compatible argument pointers
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: daniel.kruegler@googlemail.com


gcc 4.7.0 20111210 (experimental) in C++0x mode rejects the following code: 

//---------------
#include <memory>

struct T {};

T* bar() { return new T{}; }

int main()
{
  std::unique_ptr<const T[]> p;
  p.reset(bar()); // # Line 10
}
//---------------

"main.cpp||In function 'int main()':|
main.cpp|10|error: use of deleted function 'void std::unique_ptr<_Tp [],
_Dp>::reset(_Up) [with _Up = T*; _Tp = const T; _Dp = std::default_delete<const
T []>]'|
[..]include\c++\4.7.0\bits\unique_ptr.h|392|error: declared here|
"

This behaviour is in conflict with the standard. Referring to N3290
[unique.ptr.runtime] p1 b2:

"— Pointers to types derived from T are rejected by the constructors, and by
reset."

Further inspection of [unique.ptr.runtime.modifiers] does not reveal any
further constraints that could invalidate the assumption that reset should
accept the pointer to non-const T. This should also not be invalidated by the
constraints on default_delete<T[]>::operator(), because the deleter will always
be called on the internally hold pointer which has the correct type.

In regard to the seemingly difference to the constructor constraints of
[unique.ptr.runtime.ctor] p1 I would like to point to a new LWG issue:

http://cplusplus.github.com/LWG/lwg-active.html#2118

[Bug libstdc++/51609] [C++11] unique_ptr<const T[]>::reset rejects cv-compatible argument pointers

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51609

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-12-18 14:47:50 UTC ---
I'll look into this today...

[Bug libstdc++/51609] [C++11] unique_ptr<const T[]>::reset rejects cv-compatible argument pointers

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51609

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-12-19 02:24:24 UTC ---
While I agree the code is reasonable, I think an LWG issue is needed, because I
don't think GCC's behaviour is in conflict with the standard.

I don't read [unique.ptr.runtime] p1 b2 as requiring that cv-qualified types
must be accepted.  It only says types derived from T are rejected, which GCC
does.

The standard defines exactly these overloads:

void reset(pointer p = pointer()) noexcept;
void reset(nullptr_t) noexcept;
template <class U> void reset(U) = delete;

and there is nothing in [unique.ptr.runtime.modifiers] to constrain the
template.

[Bug libstdc++/51609] [C++11] unique_ptr<const T[]>::reset rejects cv-compatible argument pointers

[daniel.kruegler at googlemail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51609

--- Comment #3 from Daniel Krügler <daniel.kruegler at googlemail dot com> 2011-12-19 07:07:52 UTC ---
(In reply to comment #2)
> While I agree the code is reasonable, I think an LWG issue is needed, because I
> don't think GCC's behaviour is in conflict with the standard.

I agree, my argumentation was solely based on the text and I overlooked the
difference in the signatures in the class synopsis. So, this issue should be
closed as invalid.

[Bug libstdc++/51609] [C++11] unique_ptr<const T[]>::reset rejects cv-compatible argument pointers

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51609

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID

--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-12-19 10:26:57 UTC ---
OK, thanks, Daniel