Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: Array allocated on stack or heap Date: Fri, 17 Mar 2017 13:35:29 -0700 Organization: None to speak of Lines: 56 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit Injection-Info: mx02.eternal-september.org; posting-host="a62e3c498ac96524fc545ef94a9038ec"; logging-data="15061"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/q1TU4ZqIkng6SCaB62kDU" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:ysNVLbxR0RMQzwoFNmMQrftJiN0= sha1:LsUQLR/KYiFk5BCNK8CXghQs7MA= Xref: csiph.com comp.lang.c:106390 jacobnavia writes: > Le 17/03/2017 à 20:15, John Bode a écrit : >> The real-world implementations I know of would try to place it on the >> runtime stack, but that's strictly a function of the implementation, not >> the language definition. All the language definition specifies is *when* >> and for how long memory is to be set aside for the object, not *where*. > > The language definition defines a logical stack of nested scopes. > > You enter a scope and push the old contents of the workspace to make > place for a new scope with new data. You do your calculations and exit > the scope with (or without) result. You pop the old context and you > continue. > > You can enter a scope and exit it in a stack-like manner. Now, it is > obvious since almost all CPUs have a machine stack, that the best thing > to do is to implement the C stack using the machine's stack pointer. > > Obviously. > > I never thought somebody would discuss such obvious facts. > > The C language does imply a stack, and most implementations use the > machine stack since it is built for doing exactly that: a stack. One more time. The word "stack" is being used in two different senses here (and the C standard doesn't use it in either sense). Storage for objects with automatic storage duration is allocated in a stack-like first-in last-out manner. (C11 threading complicates this a bit, making it possible to call func0(), then call func1(), then return from func0(), then return from func1(). I haven't taken the time to look into how the standard addresses this.) Most, but not all, implementations handle this by using a "hardware stack", where stack allocations are contiguous in memory, grow in a particular direction, and are typically managed via a CPU register known as the "stack pointer". At least one implementation that's been cited here instead allocates automatic objects in a manner that doesn't place them consecutively or grow the "stack" in a particular direction; instead it does something similar to malloc() on each function call. What John wrote is perfectly correct. What you wrote is also correct, apart from your ignoring alternatives. I fail to understand why you feel the need to jump in and act as if you were correcting what John wrote. Do you actually disagree with anything John wrote? -- Keith Thompson (The_Other_Keith) kst-u@mib.org Working, but not speaking, for JetHead Development, Inc. "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"