Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: Question about use (and non-use) of "extern" Date: Tue, 03 Sep 2019 11:13:02 -0700 Organization: None to speak of Lines: 25 Message-ID: References: <86tv9ty1t4.fsf@mailhub.linuxsc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="19288dbe6d8a7942e286fe9539db231f"; logging-data="19975"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+FS10uD29pqkfm+IWIRwDM" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:ATYvi8qRGrtlXeXw4JrW3480VGg= sha1:RdoeGkRLh2jpdDX7ja+08KeouJ0= Xref: csiph.com comp.lang.c:145942 David Brown writes: [...] > If you have "int x;" in a translation unit (without any "static" > involved), that counts as an external definition of "x" with external > linkage. (6.9.2p2 and 6.9.2p1). If this identifier is used in an > expression (other than an unevaluated expression, such as a sizeof), > there must be exactly one definition of it (6.9p5). These are "shall" > rules - they are as strong as the standards get. [...] The C standard uses "shall" in two very different ways. A violation of a "shall" in a constraint (all constraints are explicitly marked as such) requires a diagnostic, just like a syntax error. *That's* as close as the C standard gets to saying something is illegal/invalid/disallowed (aside from #error). A violation of a "shall" outside a constraint, like the one in 6.9p5, cause the code to have undefined behavior, with no diagnostic required. In some cases, such rules can leave room for common extensions. -- Keith Thompson (The_Other_Keith) kst-u@mib.org Will write code for food. void Void(void) { Void(); } /* The recursive call of the void */