Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!apple!mips!pacbell.com!att!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
Message-ID: <11311@dog.ee.lbl.gov>
Date: 22 Mar 91 07:32:08 GMT
References: <1991Mar19.164037.7421@intellistor.com> <1991Mar19.183920.18911@rice.edu> <15526@smoke.brl.mil> <1991Mar22.013548.29788@fy.chalmers.se>
Reply-To: torek@elf.ee.lbl.gov (Chris Torek)
Organization: Lawrence Berkeley Laboratory, Berkeley
Lines: 27
X-Local-Date: Thu, 21 Mar 91 23:32:08 PST

In article <1991Mar22.013548.29788@fy.chalmers.se>
f90angu@fy.chalmers.se (Andreas Gunnarsson) writes:
>Are you sure? On virtual memory machines you're probably right, but in
>overlayed programs - does C really guarantee that the pointer [to
>a local static] always is valid?

Yes.

>Then that means that no static data will be overlayed? At least not if a
>pointer to it could be returned to the caller (via return or arguments
>(possibly via other assigns inside the function)).

Another alternative is `fat pointers': every pointer carries with it an
`overlay' number.  If the pointer points into a currently-unloaded data
section, that section must be loaded (somewhere).

If the pointers are built from <overlay, offset> pairs, this
essentially amounts to simulating hardware paging (as appears on most
modern CPUs) in software.

The guarantee is that, to a C programmer who `obeys all the rules',
static storage is always present.  There is no way to tell whether
it `disappears' for a while, or appears spontaneously the first time
it is used, without `cheating' (using machine-dependent code).
-- 
In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 415 486 5427)
Berkeley, CA		Domain:	torek@ee.lbl.gov