Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.std.c > #1872

Re: Reserved Identifiers

From Keith Thompson <kst-u@mib.org>
Newsgroups comp.std.c
Subject Re: Reserved Identifiers
Date 2013-01-20 19:52 -0800
Organization None to speak of
Message-ID <lnmww36vlw.fsf@nuthaus.mib.org> (permalink)
References <kc0oon$i0t$1@dont-email.me> <n9ednUPDD9h732fNnZ2dnUVZ_vmdnZ2d@earthlink.com> <kdegai$ruc$1@dont-email.me> <lnehhg92ho.fsf@nuthaus.mib.org> <kdhp85$vit$1@dont-email.me>

Show all headers | View raw


Shao Miller <sha0.miller@gmail.com> writes:
> On 1/19/2013 18:28, Keith Thompson wrote:
>> Shao Miller <sha0.miller@gmail.com> writes:
>> [...]
>>> Suppose my standard header has an #include guard __STDIO_H.  The
>>> person's argument was that this reserved identifier does not appear in
>>> the Standard, so it should not be #defined in a standard header.
>>
>> The person is clearly mistaken.
>>
>> N1570 7.1.3p1:
>
> I quoted this paragraph, upthread.  I wasn't able to conclude that the
> argument was clearly mistaken, though I believe that it is mistaken.

I'm sorry, but I just can't figure out what you find unclear about it.
Perhaps you're seeing something that I'm not.

>>      Each header declares or defines all identifiers listed in its
>>      associated subclause, and optionally declares or defines identifiers
>>      listed in its associated future library directions subclause and
>>      identifiers which are always reserved either for any use or for use
>>      as file scope identifiers.

Right:

    Each header ... optionally declares or defines ... identifiers which
    are always reserved either for any use or for use as file scope
    identifiers.

I assert that the above statement expresses a strict subset of what
the original unedited statement expresses.  I also assert that this
explicitly permits standard headers to define or declare identifiers
starting with two underscores, among other things.

> Not that it matters too much, but which of the following trees are the
> correct interpretation of that bit?:
>
>   - Each header
>     - Declares/defines all identifiers listed in its associated subclause
>     - Optionally declares/defines identifiers listed in its associated
>       future library directions subclause
>     - Declares/defines identifiers which are always reserved either
>       for any use or for use as file scope identifiers

I believe that's inconsistent with the English grammatical parsing of
the sentence, and that the third clause is absurd (it would *require*
standard headers to declare or define reserved identifiers without
stating which ones or for what purpose).

> or:
>
>   - Each header
>     - Declares/defines all identifiers listed in its associated subclause
>     - Optionally
>       - Declares/defines identifiers listed in its associated future
>         library directions subclause
>       - Declares/defines identifiers which are always reserved either
>         for any use or for use as file scope identifiers
>
> I read it as the latter.

Yes, I see no other reasonable way to read it.

>>      -- All identifiers that begin with an underscore and either an
>>         uppercase letter or another underscore are always reserved for
>>         any use.
>>
>>      -- [...]
>>
>> __STDIO_H is an identifier that's always reserved for any user.
>> <stdio.h> (I presume that's the header you're referring to) is part of
>> the implementation.  That's *exactly* the context for which it's
>> reserved.  (There are other contexts as well.)
>
> I agree, but I don't see how to draw that conclusion.

And, as I said, I don't see how you fail to draw that conclusion.

>> The standard quite
>> explicitly grants permission for such identifiers to be defined in
>> standard headers.
>>
>
> Where?  Take 7.3.1p5:
>
>   "The macros
>
>      imaginary
>
>    and
>
>      _Imaginary_I
>
>    are defined if and only if the implementation supports imaginary
> types;194) if defined, they expand to _Imaginary and a constant
> expression of type const float _Imaginary with the value of the
> imaginary unit."
>
> Here '_Imaginary_I' is an instance of an identifier that's reserved
> for any use (as well as for having file scope in the ordinary and tag
> name spaces, but that's not applicable).  It says "if and only if",
> meaning that it's optional.  So here is an example of a header
> optionally declaring/defining an identifier that's reserved for any
> use.  How do we make the jump from that to saying that _any_
> identifier with the right form is permitted?

There is no such jump.  7.3.1p5 makes a specific statement about the
identifiers "imaginary" and "_Imaginary_I".  That statement does not
imply anything about any other reserved identifiers.  It doesn't need
to; such a statement was already made in 7.1.3p1.

[...]

>> We know because the standard clearly says so.
>
> If it clearly said so, it'd say: "In a library header, an
> implementation is permitted to declare/define any identifier that has
> the form of an identifier reserved for any use.  If such an identifier
> appears in this International Standard, it shall be used by the
> implementation in accordance with its corresponding description."
>
> I don't see where it says that, as much as I believe it to be true.

[...]

>>> How do we know
>>> that all such identifiers are not reserved for future Standardization,
>>> when discussing the context of declarations/definitions in a standard
>>> header?
>>
>> They *are* reserved for future standardization.  A future standard
>> could, in principle, make __STDIO_H a new keyword.  If it did so,
>> then that particular implementation of <stdio.h> would become
>> non-conforming.  Correcting that non-conformance would be a simple
>> matter of choosing a different identifier.
>>
>
> Agreed, but I meant for the re-statement of the opposing position to
> be asking about _for_only_ future standardization, much like the
> description of 6.11.9p1:
>
>   "Macro names beginning with __STDC_ are reserved for future
> standardization."

They clearly aren't *only* for future standardization.  7.1.3p1 says so.

[snip]

Ok, so I think we've found one minor but genuine issue.

7.3.1 requires <complex.h> to define _Complex_I, and permits it to
define _Imaginary_I; both of these are identifiers of a form that is
"always reserved for any use".

7.1.3p1 says that any standard header may declare or define
identifiers that are "always reserved for any use".  Which implies,
I suppose, that <stdio.h> may define _Complex_I in some arbitrary
way, which would cause problems for a program that includes both
<stdio.h> and <complex.h>.

The only conclusion I reach from that is that (a) the standard
should probably address that, but (b) in the meantime, no sane
implementation will run afoul of it.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

Back to comp.std.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

Reserved Identifiers Shao Miller <sha0.miller@gmail.com> - 2013-01-02 02:48 -0500
  Re: Reserved Identifiers Jonathan Leffler <jleffler@earthlink.net> - 2013-01-18 22:53 -0800
    Re: Reserved Identifiers Shao Miller <sha0.miller@gmail.com> - 2013-01-19 11:06 -0500
      Re: Reserved Identifiers Keith Thompson <kst-u@mib.org> - 2013-01-19 15:28 -0800
        Re: Reserved Identifiers Shao Miller <sha0.miller@gmail.com> - 2013-01-20 16:57 -0500
          Re: Reserved Identifiers Keith Thompson <kst-u@mib.org> - 2013-01-20 19:52 -0800
      Re: Reserved Identifiers Bart van Ingen Schenau <bart@ingen.ddns.info.invalid> - 2013-01-20 10:29 +0000
        Re: Reserved Identifiers Shao Miller <sha0.miller@gmail.com> - 2013-01-20 17:06 -0500
          Re: Reserved Identifiers Bart van Ingen Schenau <bart@ingen.ddns.info.invalid> - 2013-01-21 10:56 +0000
            Re: Reserved Identifiers Shao Miller <sha0.miller@gmail.com> - 2013-01-21 18:24 -0500

csiph-web