Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!philabs!cmcl2!seismo!brl-smoke!smoke!cottrell@NBS-VMS.ARPA
From: cottrell@NBS-VMS.ARPA (COTTRELL, JAMES)
Newsgroups: net.lang.c
Subject: Stack Frames
Message-ID: <1084@brl-smoke.ARPA>
Date: Tue, 18-Feb-86 19:16:42 EST
Article-I.D.: brl-smok.1084
Posted: Tue Feb 18 19:16:42 1986
Date-Received: Wed, 19-Feb-86 20:42:24 EST
Sender: news@brl-smoke.ARPA
Lines: 34

> In article <463@ur-helheim.UUCP> dave@ur-helheim.UUCP (Raver Dave) writes:
> >
> >In c one can declare variables within any {} block.  Does a
> >{} pair *imply* new context, with stack frame shifts, etc.
> >I would have to assume so if local variables are declared
> >within the {} but if no variables are declared? ...
> >
> >The reason for asking is for ease of expansion and 
> >consistancy of formatting I often put {} blocks where
> >they are not necessary (clauses that are only one
> >statement).  Am I paying a penalty for these one-statement
> >clauses or will my trusted compiler note the context has
> >not changed and inhibit the subsequent costly stack manipulations?

To which Dagwynn responds:

> If your C compiler generates additional overhead for local
> blocks, it is not very good.  Most reasonable implementations
> reserve enough stack at function entry for the deepest local
> block nesting within the function, so that there is no
> run-time action required upon entering a local block.

Not only `not very good' but seemingly impossible. If a separate
stack frame was created, access to arguments would be different
within the new block. Still doable, but now try jumping in or
out of the block. Getting Hairy!

My experience is that the variable is allocated as if it were
declared local to the funxion, but with it's scope restricted
to the new block. Doug is correct. Fear not, it's cool.

	jim		cottrell@nbs
*/
------