Title
Problems with sized delete
Status
c++17
Section
7.6.2.9 [expr.delete]
Submitter
Richard Smith

Created on 2016-03-14.00:00:00 last changed 81 months ago

Messages

Date: 2016-12-15.00:00:00

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]
Date: 2017-02-15.00:00:00

[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.

History
Date User Action Args
2018-02-27 00:00:00adminsetstatus: review -> c++17
2017-02-06 00:00:00adminsetmessages: + msg5746
2016-03-14 00:00:00admincreate