Same issue discussed here: Why default operator delete[] can't deallocate
the memory allocated by default operator new?
<https://stackoverflow.com/questions/73434121/why-default-operator-delete-cant-deallocate-the-memory-allocated-by-default-o>

On Sun, 28 Aug 2022, 18:57 Bo Persson via Std-Proposals, <
std-proposals_at_[hidden]> wrote:

> On 2022-08-28 at 14:16, blacktea hamburger via Std-Proposals wrote:
> > Due to unspecified overhead, it is illegal to deallocate with
> > delete-expression that does not match the form of the new-expression.
> >
> >
> > However, default|operator new|and|operator delete|should not be the same.
> >
> >
> > |operator new[]|:
> >
> > [new.delete#array-4] <https://eel.is/c++draft/new.delete#array-4>
> >
> > Default behavior: Returns operator new(size), or operator new(size,
> > alignment), respectively.
> >
> > |operator delete[]:|
> >
> > [new.delete#array-14] <https://eel.is/c++draft/new.delete#array-14>:
> >
> > Default behavior: The functions that have a size parameter forward
> > their other parameters to the corresponding function without a size
> > parameter. The functions that do not have a size parameter forward
> > their parameters to the corresponding operator delete
> > (single-object) function.
> >
> > It can be seen that default |operator new[]|and|operator delete[]|simply
> > call|operator new|and|operator delete|.
> >
> >
> > However,|operator delete[]|can only deallocate the memory allocated
> > by|operator new[]|, according to[new.delete#array-9]
> > <https://eel.is/c++draft/new.delete#array-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 or operator new[](std​::​size_­t,
> > std​::​align_­val_­t) which has not been invalidated by an
> > intervening call to operator delete[].
> >
> > Therefore, the following code is illegal:
> >
> >
> > |operatordelete[](operatornew(1)); |
> >
> > |
> > |
> >
> > Because|void* operator new(std::size_t size)|does not return|void*
> > operator new[](std::size_t size)|.
> >
> >
> > However, the following code is legal:
> >
> >
> > |operatordelete(operatornew[](1)); |
> >
> > |
> > |
> >
> > According to[new.delete#single-10]
> > <https://eel.is/c++draft/new.delete#single-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.
> >
> > |void* operator new[](std::size_t size)|does return|operator new(size)|,
> > so no problem at all.
> >
> >
> > *Is it an issue?*
> >
> >
>
> It is not *illegal* for one operator delete to be able to handle the
> "wrong" kind of allocation. It is just not *required*.
>
> Some non-default operator overloads might work differently, and the spec
> just allows for that by specifiying that mixing different new-delete
> combos is not required to work.
>
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>