Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!bionet!agate!ucbvax!bloom-beacon!eru!kth.se!sunic!chalmers.se!mathrt0.math.chalmers.se!d9erikb
From: d9erikb@dtek.chalmers.se (Erik Bergersjo)
Newsgroups: comp.lang.c
Subject: Re: doing nasty things with internal static variables
Message-ID: <1991Mar22.104011.28466@mathrt0.math.chalmers.se>
Date: 22 Mar 91 10:40:11 GMT
References: <1991Mar19.183920.18911@rice.edu> <15526@smoke.brl.mil> <1991Mar22.013548.29788@fy.chalmers.se>
Sender: d9erikb@dtek.chalmers.se
Organization: Chalmers University of Technology, Gothenburg, Sweden.
Lines: 34


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

>In article <15526@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes:
>>In article <1991Mar19.183920.18911@rice.edu> fontenot@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@dtek.chalmers.se