It seems that in C++11 and earlier, exceeding certain implementation
limits at run time leads to undefined behavior (in the sense that the
standard does not define what happens).  This applies to the various
forms of stack overflow (although C++ does not have the concept of a
stack of function activation frames as such).

I wonder if N3639 intends to change this and if implementations are
expected to check that the current activation plus the requested VLA
does not exceed any run-time implementation limit.  The presence of the
bullet item "its value is such that the size of the allocated object
would exceed the implementation-defined limit (annex B implimits)"
suggest to me that such a check is required, but it's not entirely to
which limit the item refers.

At least on some systems, this check is somewhat difficult to implement
in an efficient manner if it is indeed intended to guarantee that no
undefined behavior occurs independently of the size of the VLA.

--
Florian Weimer / Red Hat Product Security Team

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

On 04/22/2013 03:47 PM, Florian Weimer wrote:
> It seems that in C++11 and earlier, exceeding certain implementation
> limits at run time leads to undefined behavior (in the sense that the
> standard does not define what happens).  This applies to the various
> forms of stack overflow (although C++ does not have the concept of a
> stack of function activation frames as such).
>
> I wonder if N3639 intends to change this and if implementations are
> expected to check that the current activation plus the requested VLA
> does not exceed any run-time implementation limit.  The presence of the
> bullet item "its value is such that the size of the allocated object
> would exceed the implementation-defined limit (annex B implimits)"
> suggest to me that such a check is required, but it's not entirely to
> which limit the item refers.

This is intended to refer to the "Size of an object" limit.  I believe
there is no limit in annex B that discusses "remaining stackspace" or
similar.  Note that the limits in annex B are compile-time characteristics,
not runtime ones.

> At least on some systems, this check is somewhat difficult to implement
> in an efficient manner if it is indeed intended to guarantee that no
> undefined behavior occurs independently of the size of the VLA.

The idea was that an implementation might have a restricted
"Size of an object" limit that is below the maximum number representable
in std::size_t.  On x86-64, there might be such a limit around 2^48.
If you exceed that limit via the multiplication "number of elements"
times "sizeof(element)", you're supposed to get an exception.

Whether your stack is big enough to hold the object remains undefined.

Jens

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

On 04/22/2013 08:25 PM, Jens Maurer wrote:
>> I wonder if N3639 intends to change this and if implementations are
>> expected to check that the current activation plus the requested VLA
>> does not exceed any run-time implementation limit.  The presence of the
>> bullet item "its value is such that the size of the allocated object
>> would exceed the implementation-defined limit (annex B implimits)"
>> suggest to me that such a check is required, but it's not entirely to
>> which limit the item refers.
>
> This is intended to refer to the "Size of an object" limit.  I believe
> there is no limit in annex B that discusses "remaining stackspace" or
> similar.  Note that the limits in annex B are compile-time characteristics,
> not runtime ones.

Yes, compile-time vs run-time part makes the reference even more confusing.

>> At least on some systems, this check is somewhat difficult to implement
>> in an efficient manner if it is indeed intended to guarantee that no
>> undefined behavior occurs independently of the size of the VLA.
>
> The idea was that an implementation might have a restricted
> "Size of an object" limit that is below the maximum number representable
> in std::size_t.  On x86-64, there might be such a limit around 2^48.
> If you exceed that limit via the multiplication "number of elements"
> times "sizeof(element)", you're supposed to get an exception.

Or if you multiply by sizeof(element) and get something that is larger
than the maximum value for size_t.  Certainly, we don't want to allocate
an array which is too small, but ...

> Whether your stack is big enough to hold the object remains undefined.

.... it would still be possible to request a size which is slightly less
than the maximum afforded by size_t, a byte count which is congruent to
a small negative value.  In common implementations, this would move the
stack pointer in the wrong direction, still triggering undefined
behavior.  If we insist on a byte count whose most significant is not
set, we can still end up crashing (or worse) because of a stack overflow.

That's why I think this part of the requirement to throw
bad_array_length does not add much in practice.  Ideally, we want to get
more predictable behavior on stack overflow, but that should be a
quality-of-implementation issue, not a conformance issue (mainly because
I don't think the standard currently has a concept of stack of
activation frames).

In any case, it's not likely that we'll be able to throw a C++ exception
on stack overflow in the foreseeable future (and I'm sure we aren't
alone in this).  The check against the compile-time limit would just
bloat the code, without addressing the underlying issue.

--
Florian Weimer / Red Hat Product Security Team

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.