Movatterモバイル変換

Proposed resolution (November, 2017)

1. Change 6.8.6.5 [basic.stc.dynamic] paragraph 3 as follows:

Any allocation and/or deallocation functions defined in a C ++program, including the default versions in the library, shall conform tothe semanticsIf the behavior of an allocation or deallocationfunction does not satisfy the semantic constraints specified in6.8.6.5.2 [basic.stc.dynamic.allocation] and 6.8.6.5.3 [basic.stc.dynamic.deallocation], thebehavior is undefined.

2. Change 6.8.6.5.2 [basic.stc.dynamic.allocation] paragraph 1 as follows:

...The value of the first parametershall beisinterpreted as the requested size of the allocation...

3. Change 6.8.6.5.2 [basic.stc.dynamic.allocation] paragraph 2 as follows:

TheAn allocation function attempts to allocate therequested amount of storage. If it is successful, itshall returnreturns the address of the start of a block of storage whoselength in bytesshall beis at least as large as the requested size.There are noconstraints on the contents of the allocated storage on return from theallocation function. The order, contiguity, and initial value ofstorage allocated by successive calls to an allocation function areunspecified.TheFor an allocation function other than areserved placement allocation function (17.6.3.4 [new.delete.placement],the pointer returnedshall beis suitablyaligned so that it can be converted to a pointer to any suitable completeobject type (17.6.3.2 [new.delete.single]) and then used to access theobject or array in the storage allocated (until the storage is explicitlydeallocated by a call to a corresponding deallocation function). Even ifthe size of the space requested is zero, the request can fail. If therequest succeeds, the value returnedshall beby areplaceable allocation function is a non-null pointer value(7.3.12 [conv.ptr])p0 different from any previouslyreturned valuep1, unless that valuep1 was subsequentlypassed toan operator deletea replaceable deallocationfunction. Furthermore, for the library allocationfunctions in 17.6.3.2 [new.delete.single] and17.6.3.3 [new.delete.array],p0shall representrepresents the address of a block of storage disjoint from thestorage for any other object accessible to the caller. The effect ofindirecting through a pointer returnedasfroma request for zero size is undefined.³⁸

4. Change 6.8.6.5.2 [basic.stc.dynamic.allocation] paragraph 3 as follows:

An allocation function that fails to allocate storage can invoke thecurrently installed new-handler function (17.6.4.3 [new.handler]),if any. [Note: A program-supplied allocation function can obtain theaddress of the currently installednew_handler using thestd::get_new_handler function(17.6.4.4 [set.new.handler]). —end note]If anAn allocation function that has a non-throwing exceptionspecification (14.5 [except.spec])fails to allocate storage,it shall returnindicates failure by returning a nullpointervalue. Any other allocation functionthat fails toallocate storage shall indicatenever returns a null pointervalue and indicates failure only by throwing an exception(14.2 [except.throw]) of a type that would match a handler(14.4 [except.handle]) of typestd::bad_alloc(17.6.4.1 [bad.alloc]).

[Accepted as a DR at the March, 2018 (Jacksonville) meeting.]

According to 6.8.6.5.2 [basic.stc.dynamic.allocation] paragraph 3,

If an allocation function declared with anon-throwingexception-specification (14.5 [except.spec])fails to allocate storage, it shall return a null pointer. Any otherallocation function that fails to allocate storage shall indicate failureonly by throwing an exception (14.2 [except.throw]) of a type thatwould match a handler (14.4 [except.handle]) oftypestd::bad_alloc (17.6.4.1 [bad.alloc]).

The use of the word “shall” to constrain runtime behavioris inappropriate, as it normally identifies cases requiring a compile-timediagnostic.