Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site alice.UUCP Path: utzoo!watmath!clyde!cbosgd!ihnp4!mhuxn!mhuxj!mhuxr!ulysses!allegra!alice!ark From: ark@alice.UUCP (Andrew Koenig) Newsgroups: net.lang.c Subject: Lattice/UNIX incompatibility Message-ID: <3220@alice.UUCP> Date: Tue, 1-Jan-85 23:56:59 EST Article-I.D.: alice.3220 Posted: Tue Jan 1 23:56:59 1985 Date-Received: Thu, 3-Jan-85 03:47:15 EST Organization: AT&T Bell Laboratories, Murray Hill Lines: 54 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.