There's a bit of jargon in this section. An external variable is what is sometimes called a global variable. The authors introduce the term automatic to refer to the local variables we've seen so far; this is a good word to remember, even if you never use it, because people will spring it on you when they're being precise, and if you don't know this usage you'll think they're talking about transmissions or something. (To be precise, ``local'' is a broader category than ``automatic''; there are both automatic and static local variables.)
Deep sentence:
If [automatic variables] are not set, they will contain garbage.Actually, if automatic variables always contained garbage, the situation wouldn't be quite so bad. In practice, they often (though not always) do contain zero or some other predictable value, and this happens just often enough to lull you into the occasional false sense of security, by making a program with an inadvertently uninitialized variable seem to work.
Deep sentence:
An external variable must be defined, exactly once, outside of any function; this sets aside storage for it. The variable must also be declared in each function that wants to access it; this states the type of the variable.The basic rule is ``define once; declare many times.'' As we'll see just below, it is not necessary for a declaration of an external variable to appear in every single function; it is possible for one external declaration to apply to many functions. (In the clause ``the variable must also be declared in each function'', the word ``declared'' is an adjective, not a verb.)
page 33
In fact, the ``common practice'' of placing ``definitions of all external variables at the beginning of the source file'' is so common that it's rare to see external declarations within functions, as in the functions on page 32. The authors are using the in-function extern declarations partly because it is an alternative style, and partly because we haven't talked about separate compilation (that is, building a single program from several separate source files) yet. Rather than jumping the gun and discussing those two topics now, I'll just mention that the discussion in section 1.10 might be a bit misleading, and that you should probably wait until we get to the complete description of the issue in section 4.4 before you commit any of this to memory.
Deep sentence:
You should note that we are using the words definition and declaration carefully when we refer to external variables in this section. ``Definition'' refers to the place where the variable is created or assigned storage; ``declaration'' refers to places where the nature of the variable is stated but no storage is allocated.Do note the careful distinction; it's an important one and one which I'll be using, too.
page 34
The authors' criticism of the second (page 32) version of the longest-line program is accurate. The revision of the longest-line program to use external variables was done only to demonstrate the use of external variables, not to improve the program in any way (nor does it improve the program in any way).
As a general rule, external variables are acceptable for storing certain kinds of global state information which never changes, which is needed in many functions, and which would be a nuisance to pass around. I don't think of external variables as ``communicating between functions'' but rather as ``setting common state for the entire program.'' When you start thinking of an external variables as being one of the ways you communicate with a particular function, and in particular when you find yourself changing the value of some external variable just before calling some function, to affect its operation in some way, you start getting into the troublesome uses of external variables, which you should avoid.
Read sequentially: prev next up top
This page by Steve Summit // Copyright 1995, 1996 // mail feedback