Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/3/84; site talcott.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!godot!harvard!talcott!kendall
From: kendall@talcott.UUCP (Sam Kendall)
Newsgroups: net.lang.c
Subject: multiple external defs (Re: Lattice/UNIX incompatibility)
Message-ID: <206@talcott.UUCP>
Date: Fri, 4-Jan-85 11:57:26 EST
Article-I.D.: talcott.206
Posted: Fri Jan  4 11:57:26 1985
Date-Received: Sun, 6-Jan-85 00:45:13 EST
References: <3220@alice.UUCP>
Organization: Sociology Dept., Harvard Univ.
Lines: 25

> 	3. Common sense indicates that the definition of
> 	an external variable should appear only once in the
> 	program text, so that its type can be changed by
> 	only altering one thing.  The logical place
> 	for such a single definition is in an include file.
> 	However, under the restrictive definition of C,
> 	this is impossible: the program breaks whether the
> 	include file says "extern" or not.
>
>	[ -- Andrew Koenig ]

On the other hand, one very good programming style dictates that the
declaration of an external variable, or any external name, appear in
two places: once in the specification of a module (in C, roughly
corresponding to a .h file) and once in the implementation of a module
(in C, a .c file); and perhaps even a third time, in the documentation
of the module.  This duplication ensures that the specification and
implementation remain compatible, since if only one changes the
compiler will complain; it encourages thinking about a program as a set
of modules with interfaces, rather than as a set of external variables;
and, of course, this duplication properly discourages external
variables by making them a pain in the butt to add (hee hee).

	Sam Kendall	  {allegra,ihnp4,ima,amd}!wjh12!kendall
	Delft Consulting Corp.	    decvax!genrad!wjh12!kendall