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

### 3789. Precondition of (not replaced) `operator delete[]`

Section: 17.7.3.3 [new.delete.array] Status: Tentatively NAD Submitter: blacktea hamburger Opened: 2022-09-25 Last modified: 2022-10-12

Priority: Not Prioritized

View all other issues in [new.delete.array].

View all issues with Tentatively NAD status.

Discussion:

Consider (`operator delete[](std::size_t)` and `operator new(std::size_t)` is not replaced):

>     operator delete[](operator new(1));

(even not replaced) `void* operator new(std::size_t)` does not return `void* operator new[](std::size_t)`. So the behavior is undefined according to 17.7.3.3 [new.delete.array] paragraph 9:

> Preconditions: `ptr` is a null pointer or its value represents the address of a block of memory allocated by an earlier call to a (possibly replaced) `operator new[](std::size_t)` or `operator new[](std::size_t, std::align_val_t)` which has not been invalidated by an intervening call to `operator delete[]`.

However, consider (`operator delete(std::size_t)` and `operator new[](std::size_t)` is not replaced):

>     operator delete(operator new[](1));

(not replaced) `operator new[](std::size_t)` simply returns `operator new(std::size_t)` according to 17.7.3.3 [new.delete.array] paragraph 4:

> Default behavior: Returns `operator new(size)`, or `operator new(size, alignment)`, respectively.

So it is well-formed according to 17.7.3.2 [new.delete.single] paragraph 10:

> Preconditions: `ptr` is a null pointer or its value represents the address of a block of memory allocated by an earlier call to a (possibly replaced) `operator new(std::size_t)` or `operator new(std::size_t, std::align_val_t)` which has not been invalidated by an intervening call to `operator delete`.

The behavior should be consistent.

[2022-10-10; Reflector poll]

Set status to "Tentatively NAD" after reflector poll.

"No reason to carve out an exception covering a case on something which can’t be observed by the program (whether the allocation operators are replaced). This just makes things more complicated for no good reason." "This would require changes to sanitizers and other dynamic analyzers, for zero practical benefit (except allowing bad code to go un-diagnosed)."

Proposed resolution:

This wording is relative to N4917.

1. Modify 17.7.3.3 [new.delete.array] as indicated:

   >     void operator delete[](void* ptr) noexcept;
   >     void operator delete[](void* ptr, std::size_t size) noexcept;
   >     void operator delete[](void* ptr, std::align_val_t alignment) noexcept;
   >     void operator delete[](void* ptr, std::size_t size, std::align_val_t alignment) noexcept;

   > > -9- Preconditions: `ptr` is a null pointer or its value represents the address of a block of memory allocated by an earlier call to a (possibly replaced) `operator new[](std::size_t)`, or `operator new[](std::size_t, std::align_val_t)`, (not replaced) `operator new(std::size_t)`, or `operator new(std::size_t, std::align_val_t)` which has not been invalidated by an intervening call to `operator delete[]`.

   > > […]