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: Thu, 16 Dec 2021 19:54:17 -0800 Organization: A noiseless patient Spider Lines: 34 Message-ID: <86o85f3mza.fsf@linuxsc.com> References: <86czm05exm.fsf@linuxsc.com> <865yro4kub.fsf@linuxsc.com> <20211217010755.f1f69829e33365c39389e163@cvine--nospam--.freeserve.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="80deed38cb7e1387fac9e84aa4dded6e"; logging-data="13626"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX182QF75D3wuQUbudMxPHv0K6P7SYHCY+Oo=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:t0y1+r/XeHg/zz8XkexjShRH+dc= sha1:0TXspezZGCtVijCEvRmpwIEGmBo= Xref: csiph.com comp.lang.c++:82672 Chris Vine writes: > On Thu, 16 Dec 2021 07:42:52 -0800 > Tim Rentsch wrote: > >> Yes, I noticed that before. I didn't comment on it because, one, >> it strikes me as incidental to the main question, and two, if we >> change the example just slightly >> >> void t() { >> volatile int a = 0; >> ++a; >> t(); >> }; >> >> int main() >> { >> t(); >> } >> >> then the program cannot be optimized into nothingness, so we >> still have the question of how an implementation is obliged to >> treat this program. And I think the answer is the same, that >> implementations are obliged to try to carry it out faithfully but >> are allowed to fail when they run out of memory. > > Isn't overflow in signed integers still undefined behavior? If so > implementations can do whatever they want should they implement tail > call optimization and so overflow on the integer. There is one 'a' variable for each level of recursion. Each 'a' starts at 0 and gets incremented to 1, stopping at that value just before the recursive call. So none of the 'a' variables ever overflows.