[vox-tech] behind the scenes of static
Micah Cowan
vox-tech@lists.lugod.org
Fri, 26 Jul 2002 19:00:04 -0700
Peter Jay Salzman writes:
> i'm well aware of what the static declaration does from a pragmatic POV,
> but i've always wondered what the connection was between static external
> and static automatic objects.
ITYM, "static external and static internal"; there isn't any such
thing as a static automatic object.
>
> it seems like it does fundamentally different things. declaring
> external variable and function names as being static seems like a
> linker-ish directive: keeping the names at filescope seems like
> something a linker would do.
Well, technically, it's the compiler that keeps it filescope, by
marking it as non-exported; but yeah, it's more or less a "linker-ish
directive".
> in contrast, declaring automatic variable static seems like a runtime
You mean "a block-scope variable"; by definition, declaring a
block-scope variable as "static" means it's not automatic anymore.
> thing. i *think* the variable allocation is done in the heap, rather
> than the stack, since the variables stick around even when the function
> stack frame is released.
>
> the apparent difference always bugged me, but i never questioned it.
>
> what is the underpinning commonality between declaring external objects
> as static and declaring automatic objects as being static? is there
> one?
>
> or do we just use the same keyword to denote two very different things?
yes, we use the same keyword to denote two very different things.
What makes all of this more confusing, is that the term "static" and
the keyword "static" are different things, and don't always coincide
(as you've seen by my above comments).
In block context, static means "allocate and initialize this object
only once, at program initialization"; it gives it "static"
allocation; whereas non-"static"-declared variables normally get
"automatic" or "dynamic" allocation.
However, at file scope, all objects are statically allocated anyway,
so that meaning would be useless. So it gets a new, totally different,
and totally non-obvious meaning: make the declared object or function
internally linked, instead of externally (as is the default). The
keyword is completely nonsensical for this use.
To make matters worse, the latest C standard (C99), defines yet
another meaning for it.
int foo(char bar[static 80]);
Decrees that all callers to foo *promise* that the array <bar> passed
in as argument, points to an array of at least 80 chars. This allows
the compiler to take some shortcuts, based on the assumption that
there really is an 80-byte object pointed to by bar. This guarantee is
*not* made by:
int foo(char bar[80]);
Which, as far as the Standard is concerned, is no different from
int foo(char bar[]);
or:
int foo(char *bar);
HTH,
Micah
--
It wouldn't be a new C standard if it didn't give a new meaning to the
word static - Peter Seebach, moderator of comp.lang.c.moderated