Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!amdcad!ames!elroy!cit-vax!oberon!bloom-beacon!mit-eddie!rutgers!princeton!udel!rochester!PT.CS.CMU.EDU!H.GP.CS.CMU.EDU!cef
From: cef@H.GP.CS.CMU.EDU (Charles Fineman)
Newsgroups: comp.lang.c
Subject: local variables (an implementation query)
Message-ID: <219@PT.CS.CMU.EDU>
Date: Fri, 23-Oct-87 02:45:29 EST
Article-I.D.: PT.219
Posted: Fri Oct 23 02:45:29 1987
Date-Received: Sun, 25-Oct-87 15:04:06 EST
Sender: netnews@PT.CS.CMU.EDU
Organization: Carnegie-Mellon University, CS/RI
Lines: 41
Keywords: compilers, local variables, implementations

My question relates to the way storage is allocated for
local varaibles (local to a block that is). For example,
how would space be allocated for an invocation of the 
following procedure:

fred()

{
  int v1;
  
  { int v2; }
    
}

The question is: "Do most C compilers allocate space for 
v2 as soon as fred is invoked, or do they wait until
control passes into the block containing v2 before
allocating space on the stack for it?"

The compilers from my experience all seem to allocated space
for *all* variables declared withing a procedure. Even those
in nested blocks. I am intrested in knowing wether I can
count on this behaviour in most real-world C compilers (or 
other languages for that matter). 

In case you want to know why:
  Part of my job is building a pre-processor for C that, among
 other things, does inline procedure calls. Since the main reason
 for doing things inline is to alleviate the overhead of
 stack allocation, any compiler not doing all-at-once allocation
 will blow away some of the efficiency of the inline calls.

  Of course, I can get around this by pulling all the local 
 declarations in the invoked procedure to the top level of the
 calling procedure, but this gets to be rather messy (in terms
 of coding and readability).


	Charles Fineman
	Carnegie-Mellon University
	cef@h.cs.cmu.edu (via seismo)