Overflow in size calculations
Section [expr.new]
James Kanze

Created on 2000-10-15.00:00:00 last changed 161 months ago


Date: 2002-10-15.00:00:00

[Picked up by evolution group at October 2002 meeting.]

Date: 2008-09-15.00:00:00

[Voted into the WP at the September, 2008 meeting.]

Date: 2008-09-15.00:00:00

Proposed resolution (September, 2008):

This issue is resolved by the resolution of issue 624, given in paper N2757.

Date: 2008-03-15.00:00:00

Note (March, 2008):

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

Date: 2001-04-15.00:00:00

Rationale (04/01):

Each implementation is required to document the maximum size of an object (Annex Annex B [implimits]). It is not difficult for a program to check array allocations to ensure that they are smaller than this quantity. Implementations can provide a mechanism in which users concerned with this problem can request extra checking before array allocations, just as some implementations provide checking for array index and pointer validity. However, it would not be appropriate to require this overhead for every array allocation in every program.

(See issue 624 for a request to reconsider this resolution.)

Date: 2020-12-15.00:00:00

(See also issue 476.)

The size requested by an array allocation is computed by multiplying the number of elements requested by the size of each element and adding an implementation-specific amount for overhead. It is possible for this calculation to overflow. Is an implementation required to detect this situation and, for instance, throw std::bad_alloc?

On one hand, the maximum allocation size is one of the implementation limits specifically mentioned in Annex Annex B [implimits], and, according to 4.1 [intro.compliance] paragraph 2, an implementation is only required to "accept and correctly execute" programs that do not violate its resource limits.

On the other hand, it is difficult or impossible for user code to detect such overflows in a portable fashion, especially given that the array allocation overhead is not fixed, and it would be a service to the user to handle this situation gracefully.

Date User Action Args
2008-10-05 00:00:00adminsetmessages: + msg1812
2008-10-05 00:00:00adminsetmessages: + msg1811
2008-10-05 00:00:00adminsetstatus: open -> cd1
2008-03-17 00:00:00adminsetmessages: + msg1621
2008-03-17 00:00:00adminsetstatus: extension -> open
2002-11-08 00:00:00adminsetmessages: + msg793
2002-11-08 00:00:00adminsetstatus: nad -> extension
2001-05-20 00:00:00adminsetmessages: + msg520
2001-05-20 00:00:00adminsetstatus: open -> nad
2000-10-15 00:00:00admincreate