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

[Mike Herrick]

On Sep 13, 2012, at 3:15 AM, John McCall wrote:

> On Sep 12, 2012, at 9:23 PM, Howard Hinnant wrote:
>> On Sep 12, 2012, at 8:07 PM, John McCall <rjmccall at apple.com> wrote:
>>> Anyway, I've asked Howard Hinnant, Apple's C++ library maintainer, to
>>> catch up on the discussion and weigh in.
>> 
>> I'm just now catching up.  Sorry to be absent.
>> 
>> I think we need to take 3 steps back.
>> 
>> My impression is that bad_array_new_length is meant to catch the case where the compiler or the run-time is required to compute an allocation size by multiplying number of elements by element size and possibly add padding.  If that computation overflows, throw bad_array_new_length.  Otherwise send it on to operator new and let it throw bad_alloc if necessary.
>> 
>> I really don't think we want to get any more complicated than that.  I don't think the benefit/cost ratio would be high if we tried to encode the number of elements times element size plus padding into bad_array_new_length.  If you catch a bad_array_new_length, then you just know you've done something outrageous.  The precise numbers aren't important.  You've used uninitialized or compromised memory for the size or number of elements.  It doesn't really matter how much you're over.  What matters is that you have a logic bug.  And it is our job to stop the program.  If someone wants to catch bad_array_new_length and try to save the program, best of luck.
> 
> I certainly agree that the goal shouldn't be to make recovery easier!  My goal was just to provide a more useful diagnostic when failing.  Programmers in managed languages find this very helpful:  knowing the exact failure condition often illuminates the problem and lets you bypass the need to reproduce.
> 
> But this is hardly the only thing you'd want better information from.  I withdraw my idea;  let's go with a nullary __cxa_throw_bad_array_new_length.

Okay, if there aren't any other objections/ideas, I'll come up with a patch.

Mike.