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