Path: csiph.com!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch
Newsgroups: comp.lang.c++
Subject: Re: Has "stack overflow" specified behavior?
Date: Mon, 13 Dec 2021 13:50:31 -0800
Organization: A noiseless patient Spider
Lines: 52
Message-ID: <86h7bc5g48.fsf@linuxsc.com>
References:
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Info: reader02.eternal-september.org; posting-host="bcf38487a73cf7e14a790d07f34a4966"; logging-data="17591"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+g3nAZvT3hSfjVj9ivVqG00py2urn/+80="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:Y/4Rq2m+jAoJktse/1nP6StJgjM= sha1:HXgOa9VFymwGWJyo9TndsNOGifk=
Xref: csiph.com comp.lang.c++:82613
Manfred writes:
> On 12/12/2021 9:42 AM, wij wrote:
>
>> void t() {
>> int a;
>> ++a;
>> t();
>> };
>>
>> int main()
>> {
>> t();
>> }
>>
>> ---
>> Has "stack overflow" specified behavior?
>
> Putting apart the specific example, the standard describes the
> behavior of the abstract machine only, but Appendix B refers to
> constraints posed by actual implementations, and that includes the
> "nesting levels of compound statements" (which in turn include
> function bodies).
> So, what you call stack overflow (an expression not found in the
> standard) is in fact a possible violation of a constraint posed by the
> implementation.
> As a kind of constraint violation this leads to UB - specifically I'd
> consider this under n4860 p4.1 clause (2.3) "If a program contains a
> violation of a rule for which no diagnostic is required, this document
> places no requirement on implementations with respect to that
> program".
First, I think you mean Annex B, not Appendix B.
Second, Annex B never uses the word 'constraint'.
Third, Annex B is informative, not normative. Nothing it says can
change the rules governing the C++ language. (Side note: Annex B
itself says in the last sentence of paragraph 2:
However, these quantities are only guidelines and do not
determine compliance.
End side note.)
The program shown above (after fixing the problem of reading an
uninitialized variable) has defined behavior, not undefined
behavior. An execution of the program in an actual machine may
fail due to running out of stack space (or any other resource)
per section 4.1 paragraph 2.1. Despite that, what happens in the
abstract machine is well-defined, and so the program has only
defined behavior, and no undefined behavior.