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)" <djgpp AT delorie DOT com>
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>	<mks4nl$1o8$1 AT speranza DOT aioe DOT org> <834mmmp7f0 DOT fsf AT gnu DOT org>	<mksolp$uta$1 AT dont-email DOT me> <83zj4enfns DOT fsf AT gnu DOT org> <mkt09d$uta$2 AT dont-email DOT me> <ctehmoF328iU1 AT mid DOT dfncis DOT de>
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: <ctehmoF328iU1@mid.dfncis.de>
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 <errno.h>:
> 
>>>>    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.