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

Groups > comp.std.c > #1870

Re: Reserved Identifiers

Show all headers | View raw

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.

>      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.
>

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

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.

>      -- 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.

> 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?

> [...]
>
>> Essentially the argument was not that reserved identifiers cannot be
>> used by an implementation (such as the _BUILTIN_abs example in a
>> foot-note), but that such identifiers must not be declared/defined in a
>> standard header.  I've tried to argue against that position by saying
>> that an implementation _does_ have freedom to declare/define such
>> identifiers in a standard header, because that is outside of the context
>> in which these identifiers are "reserved for any use".
>
> No, it's because it's *inside* the context *for which they're reserved*.
>

What I meant was that the source code, at different stages during 
translation (but after stage 3), declares/defines these reserved 
identifiers and that this is outside of the realm where it'd be a 
violation.  Sorry for confusing.

> [...]
>
>> Maybe a way to re-state the opposing position is: What makes us think
>> that an implementation can declare/define any identifier that has the
>> form of a reserved identifier, in a standard header?
>
> 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."

> There is no implication that a given copy of <stdio.h> will
> continue to conform without modification to future standards.
> A conforming C90 <stdio.h> is not a conforming C99 <stdio.h>,
> at least not without some preprocessor trickery.  Naturally, an
> implementation has to be updated to conform to the new standard.
>

Agreed.

> If you follow the rules in writing your own code (code that's not part
> of the C implementation), you most likely *won't* have to modify your
> code to make it conform to the new standard.  (This isn't always the
> case; gets() is gone, there are new keywords that weren't previously
> reserved, and so on.)
>

Agreed.

> If you define __STDIO_H in your own code, your code's behavior is
> already undefined.  This hypothetical new standard would cause your
> code to behave differently.  Again, this violates no guarantee.
>

Agreed.

-- 
- Shao Miller
--
"Thank you for the kind words; those are the kind of words I like to hear.

Cheerily,"  -- Richard Harter

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