Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA
Path: utzoo!watmath!clyde!bonnie!akgua!whuxlm!harpo!decvax!genrad!panda!talcott!harvard!seismo!brl-tgr!tgr!gwyn@BRL.ARPA
From: gwyn@BRL.ARPA (VLD/VMB)
Newsgroups: net.lang.c
Subject: Re:  4.2 extern a DISASTER (Flame)
Message-ID: <218@brl-tgr.ARPA>
Date: Sat, 27-Jul-85 20:56:27 EDT
Article-I.D.: brl-tgr.218
Posted: Sat Jul 27 20:56:27 1985
Date-Received: Wed, 31-Jul-85 00:57:49 EDT
Sender: news@brl-tgr.ARPA
Lines: 16

I don't suppose it has occurred to you that if the 4.2BSD C compiler
and linker really had botched the "extern" linkage issue, 4.2BSD
would not run?  The "common" approach to externs is just fine; in
fact Dennis Ritchie has expressed a preference for it over the
"official" (K&R or X3J11) def/ref model.  The way that "ld" handles
named common blocks is, of course, to allocate a single storage
area of size equal to the largest of the blocks having the same
name.  This area can either be explicitly initialized (.data in
effect overrides .lcom) or left uninitialized, in which case the
operating system is obliged to ensure that the area is 0-filled
upon program initialization (on UNIX, the kernel does this upon
exec).

If you are getting core dumps, etc., either your system is
terribly buggy or else you have errors in your code.  In any
case, most releases of UNIX have implemented externs this way.