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: