Path: csiph.com!weretis.net!feeder8.news.weretis.net!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 14:16:05 -0800 Organization: A noiseless patient Spider Lines: 62 Message-ID: <86czm05exm.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="U2FsdGVkX19WELAdPTs+TXm3dVdLuf80JTFNhyb0RXg=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:yhkkua92vc8rTchI9yxfPlGi7ho= sha1:IEbs5GTjCy1qUuzXHgkV8XDIuM8= Xref: csiph.com comp.lang.c++:82614 Paavo Helde writes: > 12.12.2021 10:42 wij kirjutas: > >> void t() { >> int a; >> ++a; >> t(); >> }; >> >> int main() >> { >> t(); >> } >> >> --- >> Has "stack overflow" specified behavior? > > No. Stack overflow is arguably the least specified behavior of them > all. The stack size is extremely limited (few MB), compared to the > RAM amounts current computers have (tens of GB). There is no > standard-defined way to detect stack overflow, not to speak about > handling it. That's one reason why using stack-allocated things > like std::array needs special care, especially when writing > libraries (which need to execute in a stack of unknown size and > fill-up). > > There are some implementation-defined ways though to survive stack > overflows, but it's not so easy. You cannot continue the program if > there is no more stack space, so the only way is to throw an > exception. Alas, there is no "throw" statement in the code, so this > would be an "asynchronous" exception appearing at a pretty random > place in the code, meaning that the compiler must cope with such > exceptions, which may easily slow down the whole program (witness > the /EHa compiler option in MSVC). > > BTW, your example code is not guaranteed to cause stack overflow, it > might go into an infinite loop instead because of tail recursion, or > become a zero op by optimizing the whole t() function away, either > as UB or as a code with no effect. It's important to distinguish the two realms of abstract machine and actual machine. In the abstract machine, the program shown above (after fixing the problem of reading an uninitialized variable) does have a well-defined specification, and the program as a whole has defined behavior. Whether a program has defined behavior or undefined behavior is determined solely by what goes on in the abstract machine (which may depend on values read from a file or other input device, etc, but still the question is to be answered considering only what happens in the abstract machine, with reference to any actual machine). Everything the program does has a well-defined specification, and so the program has only defined behavior, and no undefined behavior. In an actual machine, an implementation is obliged to carry out the abstract semantics only to the extent that the execution does not exceed the implementation's "resource limits", which might be anything at all, including stack space. Once such a resource limit is exceeded, the implementation has no further obligations, and may abort, or whatever. But that isn't the same as undefined behavior, which depends solely on what the standard says about operations in the abstract machine.