[Moved to DR at the November, 2014 meeting.]

Proposed resolution (February, 2014):

Change 6.7.5.5.2 [basic.stc.dynamic.allocation] paragraph 2 as follows:

...If the request succeeds, the value returned shall be a non-null pointer value (7.3.12 [conv.ptr]) p0 different from any previously returned value p1, unless that value p1 was subsequently passed to an operator delete. Furthermore, for the library allocation functions in 17.6.3.2 [new.delete.single] and 17.6.3.3 [new.delete.array], p0 shall point to a block of storage disjoint from the storage for any other object accessible to the caller. The effect of indirecting through a pointer returned as a request for zero size is undefined.³⁶

Notes from the September, 2013 meeting:

CWG agreed that changes for this issue should apply only to non-placement forms.

Additional note, April, 2013:

Concern was expressed that a pool class might provide an interface for iterating over all the pointers that were given out from the pool, and this usage should be supported.

Additional note (March, 2013):

One possibility to allow reasonable optimizations would be to require that allocation packages hide their storage in file-static variables, perhaps by adding wording such as:

Furthermore, p0 shall point to an object distinct from any other object that is accessible outside the implementation of the allocation and deallocation functions.

In 6.7.5.5.2 [basic.stc.dynamic.allocation] paragraph 2, allocation functions are constrained to return a pointer that is different from any previously returned pointer that has not been passed to a deallocation function. This does not, for instance, prohibit returning a pointer to storage that is part of another object, for example, a pool of storage. The potential implications of this for aliasing should be spelled out.

(See also issues 1027 and 1116.)