doing nasty things with internal static variables

[Erik Bergersjo]

In article <1991Mar22.013548.29788 at fy.chalmers.se> f90angu at fy.chalmers.se
(Andreas Gunnarsson) writes:

>In article <15526 at smoke.brl.mil> gwyn at smoke.brl.mil (Doug Gwyn) writes:
>>In article <1991Mar19.183920.18911 at rice.edu> fontenot at comet.rice.edu
>>(Dwayne Jacques Fontenot) writes:
>>-char *foo()
>>-{
>>-  static char string[64];
>>-  ...
>>-  return(string);
>>-}
>>
>>There's nothing particularly wrong with that usage.  Objects having
>>static storage duration exist throughout program execution.
>
>Are you sure? On virtual memory machines you're probably right, but in
>overlayed programs - does C really guarantee that the pointer always is valid?
>Then that means that no static data will be overlayed?

I don't know if the pointer is guaranteed to be valid on all systems.
However, I do know how static variables are handled on my system
(Amiga 500 - no virtual memory, Lattice C) and I think it's done in a
similar way on other machines, too. (I'd like to know if I'm wrong!)

Static variables are placed in special hunks with the hunkname "__MERGED"
in the objectfiles. At link time, all hunks with this name are - as the
name implies - merged. The resulting hunk is put into the root node.
In other words, no static data will be overlayed and a pointer to a
static variable will always be valid, even when overlays are used.
                                             . .
				Erik Bergersj o
				d9erikb at dtek.chalmers.se