This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of New status.

### 3637. `pmr::memory_resource::do_allocate` needs clarification

Section: 20.4.2 [mem.res.class] Status: New Submitter: Jonathan Wakely Opened: 2021-11-12 Last modified: 2022-01-30

Priority: 3

View all other issues in [mem.res.class].

View all issues with New status.

Discussion:

20.4.2.3 [mem.res.private] says that `pmr::memory_resource::do_allocate` returns "a pointer to allocated storage" and references 6.7.5.5.2 [basic.stc.dynamic.allocation]. But it's not really clear which parts of 6.7.5.5.2 [basic.stc.dynamic.allocation] define "allocated storage". `pmr::memory_resource::allocate` is not "an allocation function" and not a "replaceable allocation function", so "the value returned by a replaceable allocation function is a non-null pointer value" doesn't apply here, and neither does "different from any previously returned value".

Is `pmr::memory_resource::allocate` allowed to return a null pointer on success? Is it allowed to return the same address twice, without an intervening deallocation? What about if you call `pmr::monotonic_buffer_resource::release()`, is that a deallocation?

When discussed on the reflector the consensus was that returning null should not be allowed, it should throw an exception or return a valid dereferenceable pointer. The reference to 6.7.5.5.2 [basic.stc.dynamic.allocation] doesn't work to specify this though, so we should restate the requirements without directly using the core wording for `operator new`.

It was also suggested that returning the same value should not be allowed without an intervening deallocation, but that "deallocation" should not only mean a call to deallocate on the resource, but include things like `pmr::monotonic_buffer_resource::release()`, and when a memory resource's destructor returns memory to an upstream resource.

[2022-01-30; Reflector poll]

Set priority to 3 after reflector poll.

Proposed resolution: