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 20:20:44 -0800 Organization: A noiseless patient Spider Lines: 26 Message-ID: <86fsqr3lr7.fsf@linuxsc.com> References: <86czm05exm.fsf@linuxsc.com> <86a6h04pwl.fsf@linuxsc.com> 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="U2FsdGVkX1+E/wFtsD0LA/UsNRvTgXJxuHkM4KUIVeo=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:Fw07Dh/aftaba1ymUwzUb+yxyEA= sha1:6DBSEFY3luYf3EBI6EGkMA+T6Dk= Xref: csiph.com comp.lang.c++:82674 Tiib writes: > On Thursday, 16 December 2021 at 15:53:48 UTC+2, Tim Rentsch wrote: > >> Because the abstract machine is abstract, it doesn't have any >> notion of running out of memory. The semantic descriptions >> simply say another object instance is created, without any >> concern about where memory for that object might come from. > > Lack of capability of operations that provide storage to fail does > not follow from abstract machine being abstract. [...] Yes, that was poor phrasing on my part. Because of the kinds of semantic descriptions used in defining the abstract machine tend to gloss over certain kinds of details, we may reasonably expect that they don't take running out of memory into account. And that is indeed the case in the C++ standard for function calls and what happens with local variables. Section 6.9.1 paragraph 1 says this: An instance of each object with automatic storage duration (6.7.5.3) is associated with each entry into its block. Such an object exists and retains its last-stored value during the execution of the block and while the block is suspended [...] There is no mention of any possibility of running out of memory.