l i n u x - u s e r s - g r o u p - o f - d a v i s
Next Meeting:
July 7: Social gathering
Next Installfest:
Latest News:
Jun. 14: June LUGOD meeting cancelled
Page last updated:
2002 Jul 27 09:51

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
[vox-tech] behind the scenes of static
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[vox-tech] behind the scenes of static

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

 > 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[]);


  int foo(char *bar);

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
vox-tech mailing list

LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
O'Reilly and Associates
For numerous book donations.