Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10 5/3/83; site bbncca.ARPA Path: utzoo!linus!vaxine!wjh12!bbncca!keesan From: keesan@bbncca.ARPA (Morris Keesan) Newsgroups: net.lang.c Subject: Re: storage class ambiguity Message-ID: <245@bbncca.ARPA> Date: Wed, 2-Nov-83 12:03:11 EST Article-I.D.: bbncca.245 Posted: Wed Nov 2 12:03:11 1983 Date-Received: Fri, 4-Nov-83 08:08:22 EST References: <223@aecom.UUCP> Organization: Bolt, Beranek and Newman, Cambridge, Ma. Lines: 28 The key to the apparent ambiguity is found on the following page (p. 206) of Kernighan & Ritchie, in section 11.2, entitled "Scope of externals". I quote: If a function refers to an identifier declared to be extern, then somewhere among the files or libraries cnstituting the complete program there must be an external definition for the identifier. . . . The appearance of the extern keyword in an external definition indicates that strage for the identifiers being declared will be allocated in another file. Thus 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. The identifier can be initialized only in the declaration where storage is allocated. Thus, there is no real ambiguity, and though the storage class of both types of definition is extern, the distinction is between a definition which reserves space and one which doesn't. It is then obviously incorrect for there to be two declarations without the extern keyword, since space is being reserved twice, but most compilers/loaders should be able to handle the case where all the declarations for an external identifier have the extern keyword, by recognizing the special case of an undefined external, and allotting space for it, similar to the way Fortran COMMONs are handled when there is no BLOCK DATA subprogram for them.