Re: reserved identifiers (slightly OT)

Discussion in 'C Programming' started by Thomas Richter, Nov 7, 2010.

  1. superpollo wrote:
    > i understand that using something like:
    >
    > strength
    > memorandum
    > isotope
    > tolerance
    > ...
    >
    > as variable identifiers is a violation of the standard.


    Since when?

    > <OT>
    > is it possible to ask the GCC compiler to warn about this?
    > </OT>


    Why?
    Thomas Richter, Nov 7, 2010
    #1
    1. Advertising

  2. Thomas Richter

    James Kuyper Guest

    On 11/07/2010 04:34 AM, Thomas Richter wrote:
    > superpollo wrote:
    >> i understand that using something like:
    >>
    >> strength
    >> memorandum
    >> isotope
    >> tolerance
    >> ...
    >>
    >> as variable identifiers is a violation of the standard.


    Only as identifiers with external linkage. They're perfectly safe for
    use with internal linkage.

    > Since when?


    The relevant clauses are present in the C99 standard. I don't think they
    were in the C90 standard, but I can't be sure.

    Section 7.26, Future Library Directions: "All external names described
    below are reserved no matter what headers are included by the program."

    7.26.2p1: "Function names that begin with either is or to, and a
    lowercase letter may be added to the declarations in the <ctype.h> header."

    7.26.10p1: "Function names that begin with str and a lowercase letter
    may be added to the declarations in the <stdlib.h> header."

    7.26.11p1: "Function names that begin with str, mem, or wcs and a
    lowercase letter may be added to the declarations in the <string.h> header."
    James Kuyper, Nov 7, 2010
    #2
    1. Advertising

  3. Thomas Richter

    James Kuyper Guest

    On 11/07/2010 06:33 AM, superpollo wrote:
    > James Kuyper ha scritto:
    >> On 11/07/2010 04:34 AM, Thomas Richter wrote:

    ....
    >>> Since when?

    >>
    >> The relevant clauses are present in the C99 standard. I don't think
    >> they were in the C90 standard, but I can't be sure.
    >>
    >> Section 7.26, Future Library Directions: "All external names described
    >> below are reserved no matter what headers are included by the program."
    >>
    >> 7.26.2p1: "Function names that begin with either is or to, and a
    >> lowercase letter may be added to the declarations in the <ctype.h>
    >> header."
    >>
    >> 7.26.10p1: "Function names that begin with str and a lowercase letter
    >> may be added to the declarations in the <stdlib.h> header."
    >>
    >> 7.26.11p1: "Function names that begin with str, mem, or wcs and a
    >> lowercase letter may be added to the declarations in the <string.h>
    >> header."

    >
    > yes: here:
    >
    > http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1256.pdf
    >
    > starting @ p. 413
    >
    > but what about my question, anyone?


    To take one example at random, from the four you gave:

    extern char memorandum[1024];

    The identfier "memorandum" starts with "mem", and is therefore, per
    7.26.11p1, a name that might be used for a function that might be used
    in some future version of <string.h>. Per 7.26, that means that the
    external name "memorandum" is reserved, even if string.h is not
    #included, and it's reserved NOW, in C99, not just in whichever future
    version of the standard might specify the existence of such a function.
    Since function names and object names use the same name space, the fact
    that your memorandum identifies an object, rather than a function,
    doesn't have any effect on this argument.
    And, as I pointed out before, none of these issues apply to memorandum
    unless it has external linkage.
    James Kuyper, Nov 7, 2010
    #3
  4. Thomas Richter

    James Kuyper Guest

    On 11/07/2010 06:33 AM, superpollo wrote:
    > James Kuyper ha scritto:
    >> On 11/07/2010 04:34 AM, Thomas Richter wrote:

    ....
    >>> Since when?

    >>
    >> The relevant clauses are present in the C99 standard. I don't think
    >> they were in the C90 standard, but I can't be sure.
    >>
    >> Section 7.26, Future Library Directions: "All external names described
    >> below are reserved no matter what headers are included by the program."
    >>
    >> 7.26.2p1: "Function names that begin with either is or to, and a
    >> lowercase letter may be added to the declarations in the <ctype.h>
    >> header."
    >>
    >> 7.26.10p1: "Function names that begin with str and a lowercase letter
    >> may be added to the declarations in the <stdlib.h> header."
    >>
    >> 7.26.11p1: "Function names that begin with str, mem, or wcs and a
    >> lowercase letter may be added to the declarations in the <string.h>
    >> header."

    >
    > yes: here:
    >
    > http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1256.pdf
    >
    > starting @ p. 413
    >
    > but what about my question, anyone?


    To take one example at random, from the four you gave:

    extern char memorandum[1024];

    The identfier "memorandum" starts with "mem", and is therefore, per
    7.26.11p1, a name that might be used for a function that might be used
    in some future version of <string.h>. Per 7.26, that means that the
    external name "memorandum" is reserved, even if string.h is not
    #included, and it's reserved NOW, in C99, not just in whichever future
    version of the standard might specify the existence of such a function.
    Since function names and object names use the same name space, the fact
    that your memorandum identifies an object, rather than a function,
    doesn't have any effect on this argument.
    And, as I pointed out before, none of these issues apply to memorandum
    unless it has external linkage.
    James Kuyper, Nov 7, 2010
    #4
  5. James Kuyper wrote:

    > Only as identifiers with external linkage. They're perfectly safe for
    > use with internal linkage.
    >
    >> Since when?

    >
    > The relevant clauses are present in the C99 standard. I don't think they
    > were in the C90 standard, but I can't be sure.
    >
    > Section 7.26, Future Library Directions: "All external names described
    > below are reserved no matter what headers are included by the program."


    Sorry, but this looks like a very bad design decision; it also somehow
    conflicts the original design of C of *not* having any built-in
    functions but solely depend on libraries to provide such. Of course the
    intention is to allow compilers to inline memset() etc. and friends, but
    what was wrong with the old approach of using names starting with an
    underscore for such built-in functions, e.g.

    _builtin_memset

    and then have them "defined" to memset if the proper header is included?

    Then, and *only* then. It sounds very likely that this paragraph in C99
    might actually break completely correct programs, so what drove the
    committee to this statement, I wonder?

    If I don't include system headers, it should be perfectly ok to have an

    int memset = 0; /* memory not yet initialized */

    for example.

    So long,
    Thomas
    Thomas Richter, Nov 7, 2010
    #5
  6. Thomas Richter wrote:
    > James Kuyper wrote:
    >> Section 7.26, Future Library Directions: "All external names described
    >> below are reserved no matter what headers are included by the program."

    >
    >[...] It sounds very likely that this paragraph in C99
    > might actually break completely correct programs, so what drove the
    > committee to this statement, I wonder?


    Probably the fact that many real-world standard libraries break badly if
    you declare something like the following in your program:

    > int memset = 0; /* memory not yet initialized */


    and that, AFAIK, there are implementations where the startup code uses
    the standard library facilities.
    --
    Marcin Grzegorczyk
    Marcin Grzegorczyk, Nov 7, 2010
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. metaperl
    Replies:
    32
    Views:
    887
    NickC
    Sep 15, 2006
  2. Delaney, Timothy (Tim)
    Replies:
    10
    Views:
    656
    Jason
    Sep 14, 2006
  3. Steve Holden
    Replies:
    0
    Views:
    387
    Steve Holden
    Sep 13, 2006
  4. Tim H

    reserved identifiers?

    Tim H, Mar 23, 2007, in forum: C++
    Replies:
    8
    Views:
    866
    red floyd
    Mar 23, 2007
  5. Replies:
    3
    Views:
    149
    osmium
    Nov 6, 2013
Loading...

Share This Page