Mail Archives: djgpp/2015/06/05/18:45:09
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.
- Raw text -