[Bug libstdc++/110952] New: Allocator::pointer is required to be implicitly convertible from and into a native pointer

[Bug libstdc++/110952] New: Allocator::pointer is required to be implicitly convertible from and into a native pointer

[kamkaz at windowslive dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110952

            Bug ID: 110952
           Summary: Allocator::pointer is required to be implicitly
                    convertible from and into a native pointer
           Product: gcc
           Version: 11.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: kamkaz at windowslive dot com
  Target Milestone: ---

For std::list and containers based on _Rb_tree (std::(multi_)set,
std::(multi_)map) there are some non-standard requirements currently imposed on
`std::allocator_traits<Allocator>::pointer` type.

In the implementation of these containers, this pointer type (which might be a
fancy_pointer) is required to be implicitly convertible from and into native
pointers, which in this case are equivalent to
`std::pointer_traits<pointer>::element_type *`.

This bug is present in all the GCC versions I managed to test, from 6.2 until
13.2.

The proper way to convert from/into these custom pointer types is to use:
- std::__to_address(__ptr) to obtain the native pointer (which either calls
`__ptr.operator->()` or `std::pointer_traits<pointer>::to_address(__ptr)`)
- std::pointer_traits<pointer>::pointer_to(*__ptr) to get back the potentially
"fancy" pointer.

This proper way of handling allocator pointer is already implemented in
std::forward_list.

To fix this bug, the following changes must be made:

In bits/stl_tree.h:
Current:
    protected:
      _Link_type
      _M_get_node()
      { return _Alloc_traits::allocate(_M_get_Node_allocator(), 1); }

      void
      _M_put_node(_Link_type __p) _GLIBCXX_NOEXCEPT
      { _Alloc_traits::deallocate(_M_get_Node_allocator(), __p, 1); }

Fixed:
    protected:
      _Link_type
      _M_get_node()
      { 
        auto __ptr = _Alloc_traits::allocate(_M_get_Node_allocator(), 1);
        return std::__to_address(__ptr);
      }

      void
      _M_put_node(_Link_type __p) _GLIBCXX_NOEXCEPT
      {
        typedef typename _Alloc_traits::pointer _Ptr;
        auto __ptr = std::pointer_traits<_Ptr>::pointer_to(*__p);
        _Alloc_traits::deallocate(_M_get_Node_allocator(), __ptr, 1);
      }

In bits/stl_list.h:
Current:
      typename _Node_alloc_traits::pointer
      _M_get_node()
      { return _Node_alloc_traits::allocate(_M_impl, 1); }

      void
      _M_put_node(typename _Node_alloc_traits::pointer __p) _GLIBCXX_NOEXCEPT
      { _Node_alloc_traits::deallocate(_M_impl, __p, 1); }

Fixed:
      typename _Node_alloc_traits::value_type*
      _M_get_node()
      {
        auto __ptr = _Node_alloc_traits::allocate(_M_impl, 1);
        return std::__to_address(__ptr);
      }

      void
      _M_put_node(typename _Node_alloc_traits::value_type* __p)
_GLIBCXX_NOEXCEPT
      {
        typedef typename _Node_alloc_traits::pointer _Ptr;
        auto __ptr = std::pointer_traits<_Ptr>::pointer_to(*__p);
        _Node_alloc_traits::deallocate(_M_impl, __ptr, 1);
      }

This fix does not goes along with the coding style (81 characters in a line),
it might require some extra typedefs.

It is NOT a duplicate of Bug 57272 - it's not about the internal representation
of the nodes, just handling and requirements imposed on the allocator pointer.

There are no ABI issues here that I can think of.
There is a minuscule possibility it might be a breaking change for someone - if
their Fancy Pointer's implicit conversions behaved differently than its
`pointer_to` and `.operator->()` (or if they didn't provide them and relied on
implicit conversions, which are not part of the standard).

Here there is a small example reproducing the issue:
https://godbolt.org/z/fnno3jGYs

Note, that if implicit construction from `T*` and `operator T*()` are added to
the fancy pointer type, the example compiles.

(Yes, ppointer there doesn't meet the requirement of RandomAccessIterator that
is required for Allocator::pointer. However, since these functionalities are
not used by the mentioned containers, it doesn't matter here).

[Bug libstdc++/110952] Allocator::pointer is required to be implicitly convertible from and into a native pointer

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110952

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2023-08-09
             Status|UNCONFIRMED                 |NEW
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=57272
     Ever confirmed|0                           |1

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Kamil Kaznowski from comment #0)
> It is NOT a duplicate of Bug 57272 - it's not about the internal
> representation of the nodes, just handling and requirements imposed on the
> allocator pointer.

It is though, because if we actually used the allocator's pointer then this
wouldn't be an issue in the first place.

The changes need to be conditional on C++11 or later, because pointer_traits
and __to_address aren't available in C++98.