Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!uwm.edu!bionet!agate!ucbvax!dog.ee.lbl.gov!elf.ee.lbl.gov!torek
From: torek@elf.ee.lbl.gov (Chris Torek)
Newsgroups: comp.lang.c
Subject: Re: doing nasty things with internal static variables
Keywords: C, crossreference
Message-ID: <11189@dog.ee.lbl.gov>
Date: 20 Mar 91 20:09:08 GMT
References: <1991Mar19.164037.7421@intellistor.com> <1991Mar19.183920.18911@rice.edu>
Reply-To: torek@elf.ee.lbl.gov (Chris Torek)
Distribution: usa
Organization: Lawrence Berkeley Laboratory, Berkeley
Lines: 32
X-Local-Date: Wed, 20 Mar 91 12:09:08 PST

In article <1991Mar19.183920.18911@rice.edu> fontenot@comet.rice.edu
(Dwayne Jacques Fontenot) writes:
>  static char string[64];
>  ...
>  return(string);

>I am concerned about this because though I know that that static variable
>is guaranteed to always be there for the function containing it, it is
>not really guaranteed to be there (in memory) at any other time
>(correct me if I'm wrong).

Consider yourself corrected.

The *entire* difference between a local `static' and a local automatic
variable is that there is, at *all* times that the program runs, exactly
one instance of the `static', while there may be zero or more instances
of the automatic (and in fact the number of instances is exactly the
same as the number of times that automatic is in scope, i.e.,

	f(n) { int silly; if (n > 1) f(n - 1); }
	...
		f(50);

has 50 copies of `silly' floating around somewhere inside the machine%
at the deepest level of recursion).
-----
% That is, provided the optimizer has not deleted this unused variable.
  The variables are not necessarily `on a stack'; the machine may not
  even have `stacks'.  Stacks are simply a common implementation method.
-- 
In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 415 486 5427)
Berkeley, CA		Domain:	torek@ee.lbl.gov