Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!henry From: henry@utzoo.UUCP (Henry Spencer) Newsgroups: net.lang.c Subject: Re: Can #define `token-string' be empty? Message-ID: <5164@utzoo.UUCP> Date: Mon, 4-Mar-85 16:27:24 EST Article-I.D.: utzoo.5164 Posted: Mon Mar 4 16:27:24 1985 Date-Received: Mon, 4-Mar-85 16:27:24 EST References: <151@cci-bdc.UUCP> <282@cmu-cs-k.ARPA>, <363@sftri.UUCP> <5124@utzoo.UUCP>, <365@sftri.UUCP> Organization: U of Toronto Zoology Lines: 44 > The section 7.2 External data definitions of "Draft proposed C standard" > indicates that you CAN omit "extern". Please read it more carefully. In my copy of the current (11 Feb 1985) draft, section C.7.2 describes what the *definition* of an external variable looks like, and says there must be one. Note, "one", not "one or more". To quote: A declaration of an identifier of an object outside of any function without an initializer, and without a storage-class specifier [e.g. "extern"] ... constitutes a *tentative* *definition*. If a definition is encountered later in the source file, all tentative definitions are taken to be declarations of the same object... If no subsequent definition is encountered, the first tentative definition is taken to be a definition with initializer equal to 0. In other words, if the variable is initialized nowhere, then a declaration without "extern" is the definition of the variable. From C.1.2.2 we learn: If an identifier declared with external linkage is used in an expression, somewhere in the entire program there must be exactly one *external definition* for the identifier... "extern" is optional in external *declarations*. But it must not appear in the *definition*, and the tentative-definition rules boil down to saying that, in most cases of declarations outside functions, "extern" must in fact appear so that the declaration is not confused with a definition. > To give you just a bit of history, when Bell Labs were trying to enforce > K&R rule on externs many people were very unhappy, since it broke > a lot of code. That is why "multiple externs" were implemented in SVR2. Unfortunately, there exist many systems which *cannot* implement the labelled-common model of externs ("multiple externs") in any plausible way. Most any system with a non-Unix linker has this problem, in fact. So the standard most assuredly specifies that conforming programs must observe this one-definition rule. Note that "multiple externs" are explicitly mentioned in E.5.4.8 as a "common extension". -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry