doing nasty things with internal static variables

Chris Torek torek at elf.ee.lbl.gov
Fri Mar 22 17:32:08 AEST 1991


In article <1991Mar22.013548.29788 at fy.chalmers.se>
f90angu at 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 at ee.lbl.gov



More information about the Comp.lang.c mailing list