[cfe-dev] [RFC] Approach for C++1y N3639 (runtime-sized arrays with automatic storage duration)

[David Blaikie]

On Thu, May 9, 2013 at 12:11 PM, Richard Smith <richard at metafoo.co.uk> wrote:
> Hi!
>
> C++1y adds support for arrays of runtime bound (ARBs) to the C++ language.
> These are basically a restricted form of VLA, which can only be used for
> stack variables, and to which sizeof/decltype/typedef/etc can't be applied
> (though we'll still support those constructs as a GNU extension). See
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3639.html for
> details.
>
> Under N3639, we are required to throw an exception if the array bound *
> sizeof(element) calculation overflows, or if the array bound is too small.
> We're also permitted to call the global operator new/operator delete to
> acquire storage for the array, if we so choose. VLA stack usage can be
> problematic in some circumstances (especially in heavily-threaded code), so
> this may be something we want to pursue. Therefore I'm proposing the
> following implementation approach:
>
> * Add a -farb-stack-limit=N command-line option to control the maximum stack
> memory which can be used by an ARB. If the ARB doesn't fit in this limit, we
> use heap allocation instead. By default, there is no limit.
> * Add a -farb-heap-limit=N command-line option to control the maximum heap
> memory which can be used by an ARB. If the ARB doesn't fit in this limit, we
> call __cxa_throw_bad_array_length. By default, the limit is 0 (never use
> heap allocation).

What's the particular motivation for the heap limit option (when other
explicit heap allocation has no such limit (neither at the language
nor library level (things like std::vector, etc))?

> * If the bound is erroneous (too small, multiplication overflows, beyond our
> limit), we call __cxa_throw_bad_array_length. To support old C++ ABI
> libraries, we emit a weak form of this in every TU which invokes it, and the
> weak form calls __builtin_trap().
>
> Does this seem reasonable? Would we want any part of this checking (for
> instance, the overflow check + trap) in C, or in C++-before-C++14? Maybe the
> flags should be -fvla-foo instead of -farb-foo?
>
> Thanks,
> Richard
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>