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

[Dennis Handly]

>From: John McCall <rjmccall at apple.com>
>Clang handles large unsigned.  This is compiler-generated code, so
>we do know whether the value has signed type.

It seems strange that the code for signed is different than unsigned but
the Standard says that signed could overflow and implementation defined.

>Yeah, the assumption that SIZE_MAX is invalid to allocate is valid on
>basically every flat-addressed platform;  it's just not guaranteed by the
>standard.  But you can imagine a platform where individual allocations
>can't exceed some size that's significantly smaller than a pointer —

I thought you got that backwards but if sizeof(size_t) is < sizeof(uintmax),
then that would truncate that -1 to a much smaller.

But do we care?  For that architecture, the implementation-defined limit
can be set to < SIZE_MAX.

>Not that I know of; we've been quite careful.

Ok, I'm guessing I'm thinking of stuff that didn't get in that was discussed
here.

>I guess you could make an abstract argument that an
>array allocation which could have succeeded with a different bound
>should always produce std::bad_array_new_length

But isn't that what bad_alloc also says, not enough memory, you greedy
pig?

Or is this the difference between "new []" and operator new/operator new[]?
The latter two know nothing about "bounds".

>You could make a serious argument that the only allocations which
>*must* throw std::bad_array_new_length rather than just std::bad_alloc
>are the cases where you can't call the allocator because the size_t
>argument would be negative or otherwise mathematically wrong.

Which means you have to be careful for overflows in the evaluation.

>if we're creating a new, constant-sized array of PODs,

(Compile time constant?)

> we should just be
>able to call the allocator instead of calling some entrypoint that will
>check the length against some implementation limit just so that we can
>throw the perfect exception type.
John.

Yes, just let malloc check.  ;-)