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

[Mike Herrick]

On Sep 10, 2012, at 12:35 PM, John McCall wrote:

> On Sep 10, 2012, at 6:07 AM, Mike Herrick wrote:
>> Getting back to the original proposals:
>> 
>> On Sep 6, 2012, at 8:46 AM, Mike Herrick wrote:
>> 
>>> 
>>> 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).
>> 
>> It seems that option 2 is out (doesn't handle placement new[]), and option 3 has problems with signed/unsigned number of elements cases.  It appears that option 1 has had the most support (and gives the most flexibility).  Any objections (or other proposals)?
> 
> I wouldn't say option 2 is *out*, it's just not *sufficient*, in the same ways that __cxa_vec_new was never sufficient.
> 
> Would you mind writing up a formal proposal (or even a patch)?

Not at all (assuming we can figure out what the best course of action is).

>  At a high level I think the required changes are:
> 
> 1) Adding the new __cxa_throw_bad_array_new_length routine.  There's a still an open question here, I think:  it's a better user experience if std::bad_array_new_length carries the length argument.  Unfortunately (a) that's a bit complicated to encode as an operand to the routine, because we'd also need to track whether that's signed or unsigned, and (b) it looks like libc++ doesn't have space for carrying this information, and libstdc++ apparently hasn't been revised for this rule change yet.

We agree that having the length argument is desirable from a user's point of view, but it seems rather difficult for the compiler to convey this value to a library routine given that its type may be signed or unsigned and it may or may not be larger than size_t/ptrdiff_t.

> 
> 2) Including this behavior in the specification for __cxa_vec_new{,2,3}.
> 
> 3) If desired, adding __cxa_vec_new_signed{,2,3}.


We're thinking that (because of the difficulty mentioned above) it's best to make one change: namely to add __cxa_throw_bad_array_new_length(void).  This pushes the responsibility to the compiler (where the type is known), and hopefully results in generated code that can be more easily optimized.  The existing routines would be unchanged.

Mike.