Movatterモバイル変換

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

2025-12-20

624. Overflow in calculating size of allocation

[Voted into the WP at the September, 2008 meeting (resolutionin paper N2757).]

Issue 256 was closed without action,principally on the the grounds that an implementation could provide ameans (command-line option,#pragma, etc.) for requestingthat the allocation size be checked for validity, but that “itwould not be appropriate to require this overhead for every arrayallocation in every program.”

This rationale may be giving too much weight to the overhead such acheck would add, especially when compared to the likely cost ofactually doing the storage allocation. In particular, the testessentially amounts to something like

    if (max_allocation_size / sizeof(T) < num_elements)        throw std::bad_alloc();

(noting thatmax_allocation_size/sizeof(T) is acompile-time constant). It might make more sense to turn therationale around and require the check, assuming that implementationscould provide a mechanism for suppressing it if needed.

Suggested resolution:

In 7.6.2.8 [expr.new] paragraph 7, add the followingwords before the example:

If the value of the expression is such that the size of the allocatedobject would exceed the implementation-defined limit, an exception oftypestd::bad_alloc is thrown and no storage is obtained.

Note (March, 2008):

The Evolution Working Group has accepted the intent ofissue 256 and referred it to CWG foraction for C++0x (see paper J16/07-0033 = WG21 N2173).

Proposed resolution (March, 2008):

As suggested.

Notes from the June, 2008 meeting:

The CWG felt that this situation should not be treated like anout-of-memory situation and thus an exception of typestd::bad_alloc (or, alternatively, returning a null pointerfor athrow() allocator) would not be appropriate.

Proposed resolution (June, 2008):

Change 7.6.2.8 [expr.new] paragraph 8 as follows:

If the value of theexpression in adirect-new-declarator is such that the size of theallocated object would exceed the implementation-defined limit, nostorage is obtained and thenew-expression terminates bythrowing an exception of a type that would match a handler(14.4 [except.handle]) of typestd::length_error(19.2.6 [length.error]). Otherwise, ifWhen the value ofthethatexpressionin adirect-new-declarator is zero, the allocation function iscalled to allocate an array with no elements.

[Drafting note:std::length_error is thrown bystd::string andstd::vector and thus appears tobe the right choice for the exception to be thrown here.]