Proposed resolution:

This wording is relative to N4971.

1. Modify [allocator.requirements.general] as indicated:

   -2- In subclause [allocator.requirements],

   1. […]

   2. (2.10) — p denotes a value of type XX::pointer obtained by calling a1.allocate, where a1 == a,

   3. (2.11) — […],

   4. (2.12) — r denotes an lvalue of type T& obtained by the expression *p,

   5. […]

   […]

   pointer_traits<XX::pointer>::pointer_to(r)
   

   -33- Result: XX::pointer

   -34- Postconditions: Same as pLet p1 denote the return value. *p1 refers to the same object as r.

[ 2024-05-01; Reflector poll ]

Set priority to 3 after reflector poll.

"This applies to small-object optimizations too."

"An alternative way to support P0773's "near pointers" would be to require that a sentinel-node container using a "near allocator" must itself be constructed in the near segment. (This is P0773 (B) (2).)"

Currently, [allocator.requirements.general]/2.12 imposes a precondition for pointer_traits::pointer_to that r denotes an object whose storage is allocated by the allocator.

However, as mentioned in P0773R0, some containers are self-referential in current implementations, and thus a fancy pointer stored in the last node (as required by LWG 2261) needs to be able to point to a sentinel node in the container object. Given the container object can be constructed at any location, perhaps we should specify that pointer_traits::pointer_to works on any lvalue.