Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/5/84; site terak.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!seismo!hao!noao!terak!doug
From: doug@terak.UUCP (Doug Pardee)
Newsgroups: net.lang.c
Subject: Re: Forward Referencing of Static Variables OK?
Message-ID: <752@terak.UUCP>
Date: Fri, 4-Oct-85 13:14:14 EDT
Article-I.D.: terak.752
Posted: Fri Oct  4 13:14:14 1985
Date-Received: Tue, 8-Oct-85 03:14:17 EDT
References: <365@tekcbi.UUCP>
Organization: Calcomp Display Products Division, Scottsdale, AZ, USA
Lines: 28

From K&R Appendix A:
  11.2 Scope of externals
   If a function refers to an identifier declared to be extern then
   somewhere... there must be an external [as opposed to static -- dlp]
   definition for the identifier.
   ...
   The appearance of the extern keyword in an external definition
   indicates that storage for the identifiers being declared will be
   allocated in another [as opposed to the current -- dlp] file.

 11.1 Lexical scope
   The lexical scope of identifiers declared in external definitions
   persists from the definition through the end of the source file in
   which they appear.

The problem here is that an "extern" declaration tells the compiler that
the address for the data item (or function) will be supplied by the
link-editor when the program is linked; but the "static" declaration
tells the compiler that the address is "private information" to the
current module.

A system which is smart in this regard could provide a method for the
link-editor to be told that a given address is to be used only within
the current module.  But many systems aren't that "smart" -- it's only
useful for this one case.  A simpler approach is usually used: the
link-editor just isn't told about static variables.
-- 
Doug Pardee -- CalComp -- {calcom1,savax,seismo,decvax,ihnp4}!terak!doug