X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f X-Received: by 10.194.5.229 with SMTP id v5mr5089206wjv.0.1433542890651; Fri, 05 Jun 2015 15:21:30 -0700 (PDT) From: "James Kuyper (jameskuyper AT verizon DOT net)" Newsgroups: comp.os.msdos.djgpp,comp.std.c Subject: Re: DJGPP v2.05: some thoughts Date: Fri, 05 Jun 2015 18:21:29 -0400 Organization: Self Lines: 64 Message-ID: <557220E9.7040302@verizon.net> References: <55673F0B DOT 1090103 AT iki DOT fi> <83twuwwshg DOT fsf AT gnu DOT org> <55675040 DOT 9030008 AT iki DOT fi> <556F6E49 DOT 8010006 AT gmx DOT de> <556FCCDF DOT 7080005 AT iki DOT fi> <83bngvr0ef DOT fsf AT gnu DOT org> <557078B1 DOT 9040004 AT iki DOT fi> <201506041613 DOT t54GDT8m014488 AT delorie DOT com> <5570B1F7 DOT 1070509 AT iki DOT fi> <83pp5aprqw DOT fsf AT gnu DOT org> <834mmmp7f0 DOT fsf AT gnu DOT org> <83zj4enfns DOT fsf AT gnu DOT org> Mime-Version: 1.0 Injection-Info: mx02.eternal-september.org; posting-host="39e08c8e41e420e151f672c73609c593"; logging-data="11867"; mail-complaints-to="abuse AT eternal-september DOT org"; posting-account="U2FsdGVkX18XdmIXgQzkFdwOsiO1iyPdXC9Q+YYynDo=" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 In-Reply-To: Cancel-Lock: sha1:v0U4OyCn55ZLxxVyyGq03agUSBM= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Bytes: 4633 To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On 06/05/2015 05:12 PM, Hans-Bernhard Bröker wrote: > Am 05.06.2015 um 22:19 schrieb Nick Bowler: >> [cross-posting this to comp.std.c for comments] > [But forgot to implement a F'up2....] > >> On Fri, 05 Jun 2015 22:01:11 +0300, Eli Zaretskii (eliz AT gnu DOT org) wrote: > >>>> C99§7.5p4 Errors : > >>>> Additional macro definitions, beginning with E and a digit or E and >>>> an uppercase letter, may also be specified by the implementation. > >>> It's indeed present in C89, but I don't see how it reserves these >>> names. >> >> It's reserved for the implementation (DJGPP in this case) because this >> text occurs in a library subclause. > > No, it's not. It says an implementation *may* _define_ additional > identifiers, but that doesn't _reserve_ those identifiers. > > > You need to go back to the section >> on reserved identifiers. In particular: >> >> C99§7.1.3p1 Reseverd Identifiers >> >> ... Each macro name in any of the following subclauses (including >> the future library directions) is reserved for use as specified >> if any of its associated headers is included; unless explicitly >> stated otherwise (see 7.1.4). >> >> This text is also unchanged in C11. > > And it doesn't apply to the issue at hand, because none of the > non-standard errno macros is actually _in_ any of the Library subclauses. It seems pretty clear to me that 7.1.3p1 applies to names described by rules specified in a given clause (such as the rule given in 7.5p4), and not just to names that are explicitly listed in those clauses. If that weren't the case, the cross-reference to "future library directions" (7.31), could have been made far more specific. The only names actually listed in 7.31. are in 7.31.1; all of the other names described in other 16 sub-sections are given only by rules, not explicit lists. For that matter, 2/3 of the names described by 7.31.1 itself are described by rules, rather than being explicitly listed. Note that 7.31p1 says " All external names described below are reserved ...". Even if it might seem ambiguous whether "in" applies to names described by rules, it seems quite clear to me that "described" does. "Function names that begin with either is or to, and a lowercase letter ..." (7.31.2) definitely does describe "isa()", regardless of whether you agree that "isa" is actually "in" 7.31.2. However, if you insist that "in" does not apply to such names, this means that the external names described by rules given in 7.31 are reserved because of 7.31p1, but that the macros described by rules given in 7.31 are not, because of the different wording fo 7.1.3p1. That strikes me as odd, and unlikely to be the intended interpretation. In my opinion, that part of 7.31p1 is merely a restatement of the corresponding part of 7.1.3p1, using the phrase "described below" rather than "in" doesn't make any identifiers reserved that would not have already been reserved because of 7.1.3p1.