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