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

Groups > comp.std.c > #1804 > unrolled thread

Reserved Identifiers

Back to article view | Back to comp.std.c

Contents

  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

#1804 — Reserved Identifiers

 From C11:

7.1.3 Reserved identifiers

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

- All identifiers that begin with an underscore and either an uppercase 
letter or another underscore are always reserved for any use
...

2 No other identifiers are reserved. If the program declares or defines 
an identifier in a context in which it is reserved (other than as 
allowed by 7.1.4), or defines a reserved identifier as a macro name, the 
behavior is undefined.

Someone was trying to argue that given these, a literally-minded 
individual might conclude that only those __reserved _Identifiers 
actually discussed in the Standard can be declared/defined in a Standard 
header.

A program that #includes a header _might_ result in that program 
declaring/defining a _Reserved __identifier, but that'd be outside of 
the context in which it is reserved, right?

I can't quite find normative text to argue to the contrary, but there is 
certainly non-normative support, and obviously many real implementations 
use reserved identifiers.

Is there something a bit more concrete that I've missed?

- Shao Miller

[toc] | [next] | [standalone]

#1863

On 1/1/13 11:48 PM, Shao Miller wrote:
> From C11:
> 
> 7.1.3 Reserved identifiers
> 
> 1 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.
> 
> - All identifiers that begin with an underscore and either an uppercase
> letter or another underscore are always reserved for any use
> ...
> 
> 2 No other identifiers are reserved. If the program declares or defines
> an identifier in a context in which it is reserved (other than as
> allowed by 7.1.4), or defines a reserved identifier as a macro name, the
> behavior is undefined.
> 
> Someone was trying to argue that given these, a literally-minded
> individual might conclude that only those __reserved _Identifiers
> actually discussed in the Standard can be declared/defined in a Standard
> header.

That was the opinion of P J Plauger expressed in his book 'The Standard
C Library'.  On p8 of Chapter 0: "The Standard C library has fairly
clean name spaces. The library defines a couple hundred external names.
Beyond that, it reserves certain classes of names for use by the
implementors. All other names belong to the users of the language."

It applies only to a strictly conforming standard header. Other
standards such as POSIX add declarations to standard C headers, but
(nominally) those declarations have to be triggered by a define such as
_POSIX_VERSION, which is in the name space reserved for the implementation.

In practice, most implementations expose most of the extra symbols by
default. Also, including any header not defined by the standard will
typically define non-standard symbols.

> A program that #includes a header _might_ result in that program
> declaring/defining a _Reserved __identifier, but that'd be outside of
> the context in which it is reserved, right?

I'm not clear what you're asking here.  A non-standard header might
declare or define a symbol that is reserved by the C standard.  If that
leads to conflicts with the standard header, then you're invoking
'undefined behaviour'.  If the declaration has external linkage, you
could run into problems; if the declaration or definition does not have
external linkage and you don't include the standard header in the same
translation unit, you may get away with it.

> I can't quite find normative text to argue to the contrary, but there is
> certainly non-normative support, and obviously many real implementations
> use reserved identifiers.

You didn't quote all of section 7.1.3.  This is from the 2011 standard:

==SOQ==

7.1.3 Reserved identifiers

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

— All identifiers that begin with an underscore and either an uppercase
letter or another underscore are always reserved for any use.

— All identifiers that begin with an underscore are always reserved for
use as identifiers with file scope in both the ordinary and tag name spaces.

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

— All identifiers with external linkage in any of the following
subclauses (including the future library directions) and errno are
always reserved for use as identifiers with external linkage.184)

— Each identifier with file scope listed in any of the following
subclauses (including the future library directions) is reserved for use
as a macro name and as an identifier with file scope in the same name
space if any of its associated headers is included.

2 No other identifiers are reserved. If the program declares or defines
an identifier in a context in which it is reserved (other than as
allowed by 7.1.4), or defines a reserved identifier as a macro name, the
behavior is undefined.

3 If the program removes (with #undef) any macro definition of an
identifier in the first group listed above, the behavior is undefined.


184) The list of reserved identifiers with external linkage includes
math_errhandling, setjmp, va_copy, and va_end.

==EOQ==

> Is there something a bit more concrete that I've missed?

Note the start of paragraph 2; it explicitly says that anything not
reserved by paragraph 1 is not a reserved identifier according to the C
standard.  You quoted that paragraph.  It seems uncontroversial and
concrete to me.  Was it not concrete enough for you?

-- 
Jonathan Leffler                   #include <disclaimer.h>
Email: jleffler@earthlink.net, jleffler@us.ibm.com
Guardian of DBD::Informix v2013.0118 -- http://dbi.perl.org/

[toc] | [prev] | [next] | [standalone]

#1864

On 1/19/2013 01:53, Jonathan Leffler wrote:
> On 1/1/13 11:48 PM, Shao Miller wrote:
>>  From C11:
>>
>> 7.1.3 Reserved identifiers
>>
>> 1 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.
>>
>> - All identifiers that begin with an underscore and either an uppercase
>> letter or another underscore are always reserved for any use
>> ...
>>
>> 2 No other identifiers are reserved. If the program declares or defines
>> an identifier in a context in which it is reserved (other than as
>> allowed by 7.1.4), or defines a reserved identifier as a macro name, the
>> behavior is undefined.
>>
>> Someone was trying to argue that given these, a literally-minded
>> individual might conclude that only those __reserved _Identifiers
>> actually discussed in the Standard can be declared/defined in a Standard
>> header.
>
> That was the opinion of P J Plauger expressed in his book 'The Standard
> C Library'.  On p8 of Chapter 0: "The Standard C library has fairly
> clean name spaces. The library defines a couple hundred external names.
> Beyond that, it reserves certain classes of names for use by the
> implementors. All other names belong to the users of the language."
>
> It applies only to a strictly conforming standard header. Other
> standards such as POSIX add declarations to standard C headers, but
> (nominally) those declarations have to be triggered by a define such as
> _POSIX_VERSION, which is in the name space reserved for the implementation.
>
> In practice, most implementations expose most of the extra symbols by
> default. Also, including any header not defined by the standard will
> typically define non-standard symbols.
>

Thanks for your response.  Perhaps my syntax was confusing or the 
wording was ambiguous.  The person's argument was "only those reserved 
identifiers actually discussed in the Standard can be declared/defined 
in a Standard header."  That is, if you do not see a particular reserved 
identifier discussed in the Standard, then it shall not appear in a 
standard header.

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.

>> A program that #includes a header _might_ result in that program
>> declaring/defining a _Reserved __identifier, but that'd be outside of
>> the context in which it is reserved, right?
>
> I'm not clear what you're asking here.  A non-standard header might
> declare or define a symbol that is reserved by the C standard.  If that
> leads to conflicts with the standard header, then you're invoking
> 'undefined behaviour'.  If the declaration has external linkage, you
> could run into problems; if the declaration or definition does not have
> external linkage and you don't include the standard header in the same
> translation unit, you may get away with it.
>

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

>> I can't quite find normative text to argue to the contrary, but there is
>> certainly non-normative support, and obviously many real implementations
>> use reserved identifiers.
>

Another argument I can try to present that allows an implementation to 
declare/define whatever reserved identifiers they like is that 6.11.9 
would appear to be redundant, otherwise.  But this is seems to be a weak 
argument, since it's only concerned with macros and since redundancy is 
a weak argument as it is.

> You didn't quote all of section 7.1.3.  This is from the 2011 standard:
>
> ==SOQ==
>
> 7.1.3 Reserved identifiers
>
> 1 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.
>
> — All identifiers that begin with an underscore and either an uppercase
> letter or another underscore are always reserved for any use.
>
> — All identifiers that begin with an underscore are always reserved for
> use as identifiers with file scope in both the ordinary and tag name spaces.
>
> — 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).
>
> — All identifiers with external linkage in any of the following
> subclauses (including the future library directions) and errno are
> always reserved for use as identifiers with external linkage.184)
>
> — Each identifier with file scope listed in any of the following
> subclauses (including the future library directions) is reserved for use
> as a macro name and as an identifier with file scope in the same name
> space if any of its associated headers is included.
>
> 2 No other identifiers are reserved. If the program declares or defines
> an identifier in a context in which it is reserved (other than as
> allowed by 7.1.4), or defines a reserved identifier as a macro name, the
> behavior is undefined.
>
> 3 If the program removes (with #undef) any macro definition of an
> identifier in the first group listed above, the behavior is undefined.
>
>
> 184) The list of reserved identifiers with external linkage includes
> math_errhandling, setjmp, va_copy, and va_end.
>
> ==EOQ==
>
>> Is there something a bit more concrete that I've missed?
>
> Note the start of paragraph 2; it explicitly says that anything not
> reserved by paragraph 1 is not a reserved identifier according to the C
> standard.  You quoted that paragraph.  It seems uncontroversial and
> concrete to me.  Was it not concrete enough for you?
>

What I'm trying to find is an argument that implementations actually 
have the freedom to declare/define whatever reserved identifiers they 
want to, in a standard header.  Please note that this use of the word 
"define" should not be confused with "implemented-defined", but with 
either #define or with a defining declaration.

As an example, the opposing argument (that I'm trying to refute) results 
in: An implementation can have an implementation-defined type _Foo, but 
not by means of 'typedef int _Foo;' in a standard header, as that 
declares/defines an identifier reserved for any use.  That seems 
unintuitive, to me.

A "tricky part" is that when a source file #includes a standard header, 
if that header declares/defines a reserved identifier that is reserved 
for any use, then that translation unit can be said to declare/define a 
reserved identifier that is reserved for any use.  I'd like to think 
that such a usage is outside of the context in which it is reserved.  Do 
you know of a strong argument to support this?

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

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

Cheerily,"  -- Richard Harter

[toc] | [prev] | [next] | [standalone]

#1865

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:

    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.

    -- 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.)  The standard quite
explicitly grants permission for such identifiers to be defined in
standard headers.

[...]

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

[...]

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

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

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.

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

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.

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

[toc] | [prev] | [next] | [standalone]

#1870

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

[toc] | [prev] | [next] | [standalone]

#1872

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"

[toc] | [prev] | [next] | [standalone]

#1866

On Sat, 19 Jan 2013 11:06:42 -0500, Shao Miller wrote:

> On 1/19/2013 01:53, Jonathan Leffler wrote:
>> On 1/1/13 11:48 PM, Shao Miller wrote:
>>>  From C11:
>>>
>>> 7.1.3 Reserved identifiers
>>>
>>> 1 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.
>>>
<snip>

> Thanks for your response.  Perhaps my syntax was confusing or the
> wording was ambiguous.  The person's argument was "only those reserved
> identifiers actually discussed in the Standard can be declared/defined
> in a Standard header."  That is, if you do not see a particular reserved
> identifier discussed in the Standard, then it shall not appear in a
> standard header.

To counter that argument, reread clause 7.1.3/1, especially the sentense 
before the bullets (quoted above). I had to re-read it a few times before 
it sank in, but it explicitly grants leave to an implementation to 
declare, in a header file,
 - The names explicitly mentioned in the standard for that header
 - The names reserved for any use (as defined by the bullets below it)
 - The names reserved for file scope (as defined by the bullets below it)

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

Explicit text in the standard makes us think so.

> --
> - Shao Miller

Bart v Ingen Schenau

[toc] | [prev] | [next] | [standalone]

#1871

On 1/20/2013 05:29, Bart van Ingen Schenau wrote:
> On Sat, 19 Jan 2013 11:06:42 -0500, Shao Miller wrote:
>
>> On 1/19/2013 01:53, Jonathan Leffler wrote:
>>> On 1/1/13 11:48 PM, Shao Miller wrote:
>>>>   From C11:
>>>>
>>>> 7.1.3 Reserved identifiers
>>>>
>>>> 1 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.
>>>>
> <snip>
>
>> Thanks for your response.  Perhaps my syntax was confusing or the
>> wording was ambiguous.  The person's argument was "only those reserved
>> identifiers actually discussed in the Standard can be declared/defined
>> in a Standard header."  That is, if you do not see a particular reserved
>> identifier discussed in the Standard, then it shall not appear in a
>> standard header.
>
> To counter that argument, reread clause 7.1.3/1, especially the [sentence]
> before the bullets (quoted above). I had to re-read it a few times before
> it sank in, but it explicitly grants leave to an implementation to
> declare, in a header file,
>   - The names explicitly mentioned in the standard for that header
>   - The names reserved for any use (as defined by the bullets below it)
>   - The names reserved for file scope (as defined by the bullets below it)
>
> <snip>
>
>> 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?
>

I guess this wasn't a great re-statement of the opposing position.  I 
don't quite know how else to describe the difference...  Maybe:

   - There is a form of identifier that is reserved for any use
   - Identifiers with this form appear in the Standard
   - Headers can (and sometimes must) declare/define these

versus:

   - There is a form of identifier that is reserved for any use
   - Identifiers with this form appear in the Standard
   - Headers can (and sometimes must) declare/define these
   - Headers can declare/define their own identifiers with this form, 
where those identifiers aren't discussed by the Standard

> Explicit text in the standard makes us think so.
>

Thanks for the response.  I'd read 7.1.3p1 many times before posting 
(which quoted it), but cannot draw the conclusion that the opposing 
argument is clearly mistaken (please see my recent response to Keith 
Thompson for more detail, if you care to).

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

Cheerily,"  -- Richard Harter

[toc] | [prev] | [next] | [standalone]

#1874

On Sun, 20 Jan 2013 17:06:18 -0500, Shao Miller wrote:

> I guess this wasn't a great re-statement of the opposing position.  I
> don't quite know how else to describe the difference...  Maybe:
> 
>    - There is a form of identifier that is reserved for any use 
>    - Identifiers with this form appear in the Standard 
>    - Headers can (and sometimes must) declare/define these
> 
> versus:
> 
>    - There is a form of identifier that is reserved for any use 
>    - Identifiers with this form appear in the Standard 
>    - Headers can (and sometimes must) declare/define these
>    - Headers can declare/define their own identifiers with this form,
> where those identifiers aren't discussed by the Standard

Then I would ask those who hold the first position this:
"Identifiers like _Imaginary_I and _Exit are already covered by the very 
first words of clause 7.3.1/1 ("Each header declares or defines all 
identifiers listed in its associated subclause"), so why would the 
additional text about optionally allowing reserved identifiers be needed?"

As additional evidence for the second stance, I would give this quote 
from K&R2 (Appendix B):
<quote>
External identifiers that begin with an underscore are reserved for use 
by the library, as are all other identifiers that begin with an 
underscore and an upper-case letter or another underscore.
</quote>

> 
> --
> - Shao Miller

Bart v Ingen Schenau

[toc] | [prev] | [next] | [standalone]

#1875

On 1/21/2013 05:56, Bart van Ingen Schenau wrote:
>
> As additional evidence for the second stance, I would give this quote
> from K&R2 (Appendix B):
> <quote>
> External identifiers that begin with an underscore are reserved for use
> by the library, as are all other identifiers that begin with an
> underscore and an upper-case letter or another underscore.
> </quote>
>

Excellent reference.  Thank you for sharing that.  It'll be useful when 
the discussion continues in the other C-devoted forum where the 
discussion first took place.

(Other readers: Sorry about the thank-you note; e-mail filters sometimes 
have false positives.)

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

Cheerily,"  -- Richard Harter

[toc] | [prev] | [standalone]

Back to top | Article view | comp.std.c

csiph-web