Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!gatech!purdue!haven!ncifcrf!nlm-mcs!adm!smoke!gwyn From: gwyn@smoke.BRL.MIL (Doug Gwyn) Newsgroups: comp.lang.c Subject: Re: question about scope & linkage Keywords: scope, linkage Message-ID: <10718@smoke.BRL.MIL> Date: 12 Aug 89 07:44:58 GMT References: <57257@tut.cis.ohio-state.edu> <1001@virtech.UUCP> <14270@haddock.ima.isc.com> <1002@virtech.UUCP> Reply-To: gwyn@brl.arpa (Doug Gwyn) Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 22 In article <1002@virtech.UUCP> cpcahil@virtech.UUCP (Conor P. Cahill) writes: > ...In the alternate formulation, which is usual in UNIX systems and > recognized as a common extension by the Standard, ... However, note that this "common extension" (so-called because that is the title of the section of the Standard wherein it is described) violates the requirements of the Standard. The "common extensions" are not in the enforceable part of the Standard, and some of us think they have no business being printed as an apparent part of the Standard. (We were outvoted, though; the "Common Extensions" section had political if not technical value.) int i; at file scope (assuming there is no other file-scope definition for i in the same translation unit) does reserve storage for i, and it does have the initial value 0. A standard-conforming translator is obliged to enforce this. Since it also has external linkage, the occurrence of int i = 17; at file scope in another translation unit directly conflicts with the 0 initializer of the first translation unit. These rules date back to the first edition of K&R.