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

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

Section: 17.6.3.3 [new.delete.array] Status: NAD Submitter: blacktea hamburger Opened: 2022-09-25 Last modified: 2022-11-30

Priority: Not Prioritized

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

View all issues with 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.6.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.6.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.6.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)."

[2022-11-30 LWG telecon. Status changed: Tentatively NAD → NAD.]

Proposed resolution:

This wording is relative to N4917.

1. Modify 17.6.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[].

   […]