This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21 Core Issues List revision 116a. See http://www.open-std.org/jtc1/sc22/wg21/ for the official list.

2024-12-19

2248. Problems with sized delete

[Adopted at the February/March, 2017 meeting.]

Consider:

   T *p = new (::operator new(sizeof(T) + 100)) T;
   delete p;

It is infeasible for the implementation to infer the size of the block of storage, yet the standard does not permit undefined behavior for this case.

Proposed resolution (December, 2016):

Change 7.6.2.9 [expr.delete] paragraph 11 as follows:

When a delete-expression is executed, the selected deallocation function shall be called with the address of the block of storage to be reclaimed most-derived object in the delete object case, or the address of the object suitably adjusted for the array allocation overhead (7.6.2.8 [expr.new]) in the delete array case, as its first argument. If a deallocation function with a parameter of type std::align_val_t is used, the alignment of the type of the object to be deleted is passed as the corresponding argument. If a deallocation function with a parameter of type std::size_t is used, the size of the block most-derived type, or of the array plus allocation overhead, respectively, is passed as the corresponding argument. [Note: If this results in a call to a usual deallocation function, and either the first argument was not the result of a prior call to a usual allocation function or the second argument was not the corresponding argument in said call, the behavior is undefined (17.6.3.2 [new.delete.single], 17.6.3.3 [new.delete.array]). —end note]