On Thu, May 9, 2013 at 1:24 PM, David Blaikie <span dir="ltr"><<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Thu, May 9, 2013 at 12:11 PM, Richard Smith <<a href="mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>> wrote:<br>
> Hi!<br>
><br>
> C++1y adds support for arrays of runtime bound (ARBs) to the C++ language.<br>
> These are basically a restricted form of VLA, which can only be used for<br>
> stack variables, and to which sizeof/decltype/typedef/etc can't be applied<br>
> (though we'll still support those constructs as a GNU extension). See<br>
> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3639.html" target="_blank">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3639.html</a> for<br>
> details.<br>
><br>
> Under N3639, we are required to throw an exception if the array bound *<br>
> sizeof(element) calculation overflows, or if the array bound is too small.<br>
> We're also permitted to call the global operator new/operator delete to<br>
> acquire storage for the array, if we so choose. VLA stack usage can be<br>
> problematic in some circumstances (especially in heavily-threaded code), so<br>
> this may be something we want to pursue. Therefore I'm proposing the<br>
> following implementation approach:<br>
><br>
> * Add a -farb-stack-limit=N command-line option to control the maximum stack<br>
> memory which can be used by an ARB. If the ARB doesn't fit in this limit, we<br>
> use heap allocation instead. By default, there is no limit.<br>
> * Add a -farb-heap-limit=N command-line option to control the maximum heap<br>
> memory which can be used by an ARB. If the ARB doesn't fit in this limit, we<br>
> call __cxa_throw_bad_array_length. By default, the limit is 0 (never use<br>
> heap allocation).<br>
<br>
</div>What's the particular motivation for the heap limit option (when other<br>
explicit heap allocation has no such limit (neither at the language<br>
nor library level (things like std::vector, etc))?</blockquote><div><br></div><div>Perhaps it would make more sense here to just have a flag to say whether we will ever use heap allocation as a fallback. I can certainly imagine situations where you want a stack limit but never want to fall back to the heap (and equally, a stack limit and a heap fallback seems very useful).</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
> * If the bound is erroneous (too small, multiplication overflows, beyond our<br>
> limit), we call __cxa_throw_bad_array_length. To support old C++ ABI<br>
> libraries, we emit a weak form of this in every TU which invokes it, and the<br>
> weak form calls __builtin_trap().<br>
><br>
> Does this seem reasonable? Would we want any part of this checking (for<br>
> instance, the overflow check + trap) in C, or in C++-before-C++14? Maybe the<br>
> flags should be -fvla-foo instead of -farb-foo?<br>
><br>
> Thanks,<br>
> Richard<br>
><br>
</div>> _______________________________________________<br>
> cfe-dev mailing list<br>
> <a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
><br>
</blockquote></div><br>