Created on 2014-04-12.00:00:00 last changed 20 months ago
Proposed resolution (November, 2017)
Change 126.96.36.199 [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 to the semanticsspecified in 188.8.131.52.2 [basic.stc.dynamic.allocation] and 184.108.40.206.3 [basic.stc.dynamic.deallocation].
Change 220.127.116.11.2 [basic.stc.dynamic.allocation] paragraph 1 as follows:
...The value of the first parameter
shall beinterpreted as the requested size of the allocation...
Change 18.104.22.168.2 [basic.stc.dynamic.allocation] paragraph 2 as follows:
Theallocation function attempts to allocate the requested amount of storage. If it is successful, it shall returnthe address of the start of a block of storage whose length in bytes shall beat least as large as the requested size. There are no constraints on the contents of the allocated storage on return from the allocation function.The order, contiguity, and initial value of storage allocated by successive calls to an allocation function are unspecified. Thepointer returned shall besuitably aligned so that it can be converted to a pointer to any suitable complete object type (22.214.171.124 [new.delete.single]) and then used to access the object or array in the storage allocated (until the storage is explicitly deallocated by a call to a corresponding deallocation function). Even if the size of the space requested is zero, the request can fail. If the request succeeds, the value returned shall bea non-null pointer value (7.3.12 [conv.ptr]) p0 different from any previously returned value p1, unless that value p1 was subsequently passed to an operator delete. Furthermore, for the library allocation functions in 126.96.36.199 [new.delete.single] and 188.8.131.52 [new.delete.array], p0 shall representthe address of a block of storage disjoint from the storage for any other object accessible to the caller. The effect of indirecting through a pointer returned asa request for zero size is undefined.38
Change 184.108.40.206.2 [basic.stc.dynamic.allocation] paragraph 3 as follows:
An allocation function that fails to allocate storage can invoke the currently installed new-handler function (220.127.116.11 [new.handler]), if any. [Note: A program-supplied allocation function can obtain the address of the currently installed new_handler using the std::get_new_handler function (18.104.22.168 [set.new.handler]). —end note]
If anallocation function that has a non-throwing exception specification (14.5 [except.spec]) fails to allocate storage, it shall returna null pointer . Any other allocation function that fails to allocate storage shall indicatefailure only by throwing an exception (14.2 [except.throw]) of a type that would match a handler (14.4 [except.handle]) of type std::bad_alloc (22.214.171.124 [bad.alloc]).
[Accepted as a DR at the March, 2018 (Jacksonville) meeting.]
According to 126.96.36.199.2 [basic.stc.dynamic.allocation] paragraph 3,
If an allocation function declared with a non-throwing exception-specification (14.5 [except.spec]) fails to allocate storage, it shall return a null pointer. Any other allocation function that fails to allocate storage shall indicate failure only by throwing an exception (14.2 [except.throw]) of a type that would match a handler (14.4 [except.handle]) of type std::bad_alloc (188.8.131.52 [bad.alloc]).
The use of the word “shall” to constrain runtime behavior is inappropriate, as it normally identifies cases requiring a compile-time diagnostic.
|2020-12-15 00:00:00||admin||set||status: dr -> cd5|
|2018-04-11 00:00:00||admin||set||status: tentatively ready -> dr|
|2018-02-27 00:00:00||admin||set||messages: + msg5852|
|2018-02-27 00:00:00||admin||set||status: drafting -> tentatively ready|
|2014-07-07 00:00:00||admin||set||status: open -> drafting|