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

Groups > comp.std.c > #1864

Re: Reserved Identifiers

Show all headers | View raw

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

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