[cxx-abi-dev] Run-time array checking

[Mike Herrick]

As part of the changes for C++11, there are new requirements on checking of the value of the expression in a new[] operation.  5.3.4p7 says:

When the value of the expression in a noptr-new-declarator is zero, the allocation function is called to
allocate an array with no elements. If the value of that expression is less than zero or such that the size
of the allocated object would exceed the implementation-defined limit, or if the new-initializer is a
braced-init-list for which the number of initializer-clauses exceeds the number of elements to initialize, no storage
is obtained and the new-expression terminates by throwing an exception of a type that would match a
handler (15.3) of type std::bad_array_new_length (18.6.2.2).

We're wondering if there needs to be an ABI change here to support this.

Here are some basic strategies for doing the run-time checking:

1) Have the compiler generate inline code to do the bounds checking before calling the existing runtime routines.  The problem with this is that there is no IA-64 ABI standard way to throw a std::bad_array_new_length exception once a violation has been detected (so we'd need to add something like __cxa_throw_bad_array_new_length).

2) Have the runtime libraries do the checking and throw std::bad_array_new_length as needed.  In order to do this (in a backwards compatible way) I think we'd need to add new versions of __cxa_vec_new2/__cxa_vec_new3 where the element_count is signed and the number of initializers in the array is passed as a new argument.

3) A new routine, say __cxa_vec_new_check, that takes a signed element_count, element_size, and number of initialized elements and does all necessary checks, throwing std::bad_array_new_length if required, otherwise returning.  Compilers would insert a call to the new routine before any call to __cxa_vec_new* (when the number of elements isn't known at compile time).

We're leaning towards the first option in the hopes that a back end can more easily optimize away some of the added checking, but perhaps someone with more back end experience can shed some light on which of these options would generate the best code.

Mike Herrick
Edison Design Group