doing nasty things with internal static variables

[Andreas Gunnarsson]

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);
>-}
>-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).
>
>There's nothing particularly wrong with that usage.  Objects having
>static storage duration exist throughout program execution.  Now, if
>you had omitted the "static" storage-class specifier, the array would
>have been an automatic variable, and auto storage does "evaporate"
>upon leaving the block in which it is declared.

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? 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)).
If I'd need to pass a pointer to static data back, I'd define it as a global
variable instead of local. I think it looks ugly, but since I'm not sure it'll
work with the next compiler i wouldn't take the chance.
-- 
==============================================================================
73 es 88 de SM7TLS          f90angu at fy.chalmers.se          Andreas Gunnarsson
==============================================================================