Lattice/UNIX incompatibility

Andrew Koenig ark at alice.UUCP
Wed Jan 2 14:56:59 AEST 1985


I recently posted a note complaining that Lattice C
enforces the "single external declaration rule,"
which makes it harder to port programs from UNIX systems.

I did not expect the flood of messages that would ensue.

Let me correct some misconceptions.

First, the problem.  K&R [page 206] states:

	...in a multi-file program, an external data definition
	without the extern specifier must appear in exactly
	one of the files.  Any other files which wish to
	give an external definition for the identifier must
	include the extern in the definition.

Thus, on the surface, it would appear that there is no issue.
However, most UNIX systems permit extern to be omitted entirely
in all the files.  In effect, the linker permits an external
variable to be multiply defined.  This extension is so pervasive
that its use is also pervasive, to the extent that porting
almost any multi-file program to a compiler that enforces the
restriction is made much harder as a result.

On the surface, then, it would appear that I am merely campaigning
for my pet feature.  However, there is more to it than that:

	1. The 'feature' is actually the way things were
	at first, and still are in most UNIX systems.

	2. The restriction was thrown in as a sop to some
	non-UNIX operating systems, whose linkers make it
	tough to implement C without the restriction
	(although PL/I has exactly the same semantics for
	its external variables as "unrestricted" C, which
	makes it hard for me to understand why C can't
	do it on IBM systems).

	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.

	4. C++ enforces its own version of the restriction
	because it has to be able to generate C for compilers
	that also enforce the restriction.

I do not enjoy using programming systems that force me
to change things to make life easier for the computer.
I believe that machines should be my servants, not vice versa.



More information about the Comp.lang.c mailing list