Path: utzoo!utgpu!attcan!uunet!husc6!purdue!umd5!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.lang.c
Subject: `static'
Message-ID: <12840@mimsy.UUCP>
Date: 4 Aug 88 21:17:03 GMT
References: <644@m10ux.UUCP> <503@draken.nada.kth.se>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 63

In article <503@draken.nada.kth.se> pk-tle@nada.kth.se (Tommy Levitte) writes:
(text in []s his, but moved)
>There are two kinds of statics:
> - External statics [defined outside functions].
> - Internal statics [defined  inside functions].
>External statics are reachable in the whole file, but internal statics are only
>available in the function in which they are defined.

This is correct, but mixes up two separate concepts (well, perhaps
this is reasonable, since the same keyword is used for both).

>A string constant is an exception to this rule.

This, however, is false.  (You too have confused scoping and storage,
at least in this explanation.)

[text written _like_this_ represents emphasis]

Static has two meanings.  It is a _storage_class_specifier_, and it is
a (link-time) _scope_specifier_.  These should be considered separately.

First, all local variables, no matter what their storage class, are
locally (block) scoped.  The differences between the declarations of x,
y, and z below are in their storage classes, not their scopes.

	f() {
		int x;		/* auto storage (the default) */
		register int y;	/* register storage */
		static int z;	/* static storage */
		...

All of these variables are accessible in f, and in any sub-blocks within
f() (unless they are hidden by a redeclaration).  `x' and `y' come into
existence when f() is called, and disappear when f() returns; new instances
appear if f() is called recursively.  `z', however, exists independent of
f(): it has _static_storage_.  There is only one copy of z; it is always
there.  It can only be _named_ from f(), but it is there whether it can
be named or not.

While all local variables are of storage class `auto' unless otherwise
specified, global variables and functions are _always_ of storage class
`static'.  That frees the keyword for its second meaning: global
variables and functions can be of _file_scope_ or _program_scope_.
Normally, globals have program scope, but adorning a global definition
with the keyword `static' makes it instead have file scope.  Objects
with file scope cannot be named outside of the source file that
defines them; objects with global scope can be so named, by declaring
them as external in another source file.  Essentially, tagging a
function or a global variable `static' makes it hidden, so that no one
but you can find it.  (It also allows you to make two or more different
objects with the same name, whether or not you meant to do so, by using
the same name in different files.  Since each file refuses to disclose
its statics, each file gets only its own version.)

Finally, returning to string constants: these are unnamed objects, and
hence the scoping rules for names are irrelevant.  There simply is no
name to be scoped.  The objects do, however, have static storage duration:
they exist at all times.  Thus, once you have a pointer to a string
constant, you can follow that pointer at any time.  The string shall
not vanish from underfoot, unless the whole program vanishes with it.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris