[llvm-bugs] [Bug 49241] New: std::to_address should not require std::pointer_traits<Pointer>::element_type to be well-formed

via llvm-bugs llvm-bugs at lists.llvm.org
Wed Feb 17 22:14:54 PST 2021


https://bugs.llvm.org/show_bug.cgi?id=49241

            Bug ID: 49241
           Summary: std::to_address should not require
                    std::pointer_traits<Pointer>::element_type to be
                    well-formed
           Product: libc++
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: All Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: schottm at google.com
                CC: llvm-bugs at lists.llvm.org, mclow.lists at gmail.com

Per [pointer.conversion] ¶ 3 (http://eel.is/c++draft/pointer.conversion#3), if
the argument to std::to_address matches the overload for const Pointer&, it
uses std::pointer_traits<Pointer>::to_address(p) if that is well-formed,
otherwise to_­address(p.operator->()).

Nowhere does it say that std::pointer_traits<Pointer> has to exist at all in
the case where operator->() is chosen. However, in __memory/pointer_traits.h[1]
we see that the return type is dictated as
std::pointer_traits<Pointer>::element_type* despite the fact that there are
many types in the wild that overload operator-> and *should* be expected to
work with std::to_address, but don't.

See [2] for an example of a type that should work per the standard but doesn't
unless we define std::pointer_traits<Pointer>::element_type. (It appears that
godbolt uses libstdc++ even when you select clang, but from my own local
testing [and inspection of libc++'s implementation], I've determined that
libc++ has the same problem.)

It looks like the original implementation in [3] was fine (unless you were on
C++17) but it was broken in [4] when __to_raw_pointer and __to_address were
merged. It seems that priority was given to using __to_address() as an internal
function, and this existing usage clashed with the public std::to_address in
non-obvious ways.

[1]:
https://github.com/llvm/llvm-project/blob/da59c2e4dc1c7b502cc2098247b2ee38ac297e0c/libcxx/include/__memory/pointer_traits.h#L199

[2]: https://godbolt.org/z/47cxTG

[3]: https://reviews.llvm.org/D35470

[4]: https://reviews.llvm.org/rG0068c5913999b14627c27433c8d846a2ef5fbe00

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20210218/47ae225c/attachment.html>


More information about the llvm-bugs mailing list