name space -- C Language

C name-space rules
The term
name space
refers to the ``list'' where the translator records an identifier.
Each name space holds a different set of identifiers.
If two identifiers are spelled exactly the same and appear within
the same scope but are not in the same name space,
they are not considered to be identical.

The five varieties of name space, as follows:

Macro Names
     Macro  names  introduced  with  #define  are special.   Because  macro
     replacement happens  before the program text is  scanned for the other
     classes of names,  macro names exist in a global  name space that pays
     no  heed  to  the rules  below.   See  the  description of  name-space
     pollution, below, for more on this.

Label Names
     The translator treats every identifier followed by a colon `:' or that
     follows a goto statement as a label.

Tags A tag is the name that follows the keywords struct, union, or enum. It
     names the type of object so declared.

Members
     A member names a field within  a structure or a union. A member can be
     accessed via  the operators `.'  or `->'.  Each  structure or union
     type has a separate name space for its members.

Ordinary identifiers
     These  name  ordinary  functions  and  variables.   For  example,  the
     expression

         int example;

     declares the  ordinary identifier  example to  name an object  of type
     int.

Name-Space Pollution

The ANSI  Standard and the  POSIX Standard recognize  special problems that
relate to the above classes of  name space and to the names supplied to the
user by  the translator  or the  #include mechanism.  They  provide special
rules that govern what names a program and an implementation can define.

Although the above rules are good  at resolving conflict, in the context of
a large programming project  (which the standard C library is, effectively)
they  are not  always  sufficient.  First,  there is  the possibility  that
definitions in  library header files may conflict with  each other, or with
user definitions.   Second, an internal definition  in the standard library
may conflict with a user definition that happens to have the same name.

The  ANSI  Standard  defines  rules  that  set aside  some  names  for  the
implementation.   The implementation  can use  only  these names,  and user
applications cannot  use them.  When implementations  and applications both
obey these  rules, a user  program cannot conflict  with a definition  in a
system header file.  The rules are as follows:

-> Any name that begins with an  underscore followed by a capital letter or
   underscore  is reserved  for  use by  the implementation.   Applications
   should not  use any symbols  of this form except  to define feature-test
   macros (e.g., _POSIX_SOURCE, see below).

-> Any name that begins with  an underscore followed by a lower-case letter
   is reserved for use by the  application if the name is internal (such as
   a static symbol or a tag- or member-name).  Macro names of this form are
   forbidden, because they do not  obey the other name-space rules above: a
   user-level  macro  definition  could cause  a  conflict  with a  private
   structure-member defined in a system header.

-> C++  reserves  for   the  implementation  all  names  that  contain  two
   underscores.

-> The  Standard forbids external  identifiers (i.e.,  non-static functions
   and variables) that match any of the function or variable defined in the
   C standard.

-> If a program  #includes a standard library header file,  it cannot use a
   macro  definition that  matches  the name  of any  function or  variable
   defined in any standard library header.

These rules are  supplemented with rules that govern the  use of names that
are defined  in any library  header described in  the ANSI Standard  or the
POSIX Standard.   The following  gives the  rules that apply  to individual
header files:

<errno.h>
     The implementation can define  extra macros that begin with the letter
     `E'.

<signal.h>
     The implementation can define extra macros that begin with SIG_.

If  an  application needs  to  use  any function  that  the POSIX  Standard
defines,  it  should   contain  the  following  line  before  any  #include
directives:

    #define _POSIX_SOURCE 1

This sets the _POSIX_SOURCE feature-test macro.  If this is done, the POSIX
Standard  reserves  symbols  for  some  header  files.  If  an  application
includes one of the following header  files, it must not use any of symbols
reserved for that header:

<dirent.h>
     Reserved prefix: d_.

<fcntl.h>
     Reserved  prefixes: l_,  F_, O_, and  S_. Reserved  symbols: SEEK_CUR,
     SEEK_END, and SEEK_SET.

<grp.h>
     Reserved prefix: gr_.

<limits.h>
     Reserved suffix: _MAX.

<pwd.h>
     Reserved prefix: pw_.

<signal.h>
     Reserved prefixes: sa_, SIG_, and SA_.

<sys/stat.h>
     Reserved prefixes: st_ and S_.

<sys/times.h>
     Reserved prefix: tms_.

If an application #includes any header described in the POSIX Standard, all
symbols with the suffix _t are reserved.

Note that  the symbols defined  above that begin with  an upper-case letter
may  be  used  by  an  application  after the  #include  directive  if  the
application uses  an #undef directive to  cancel any conflicting definition
supplied by the header.

Example

The following program illustrates the  concept of name space.  It shows how
the identifier  foo can be  used numerous times  within the same  scope yet
still be distinguished.   This is extremely poor programming style.  Please
do not write programs like this.

#include <stdio.h>
#include <stdlib.h>

/* structure tag */
struct foo {
    /* structure member */
    struct foo *foo;
    int bar;
};

main()
{
    /* ordinary identifier */
    struct foo *foo;
    int i = 0;

    foo = (struct foo *)malloc(sizeof(*foo));
    foo->bar = ++i;
    foo->foo = NULL;

/* label */
foo:    printf("What kind of \"foo\" am I?\n");
    if (foo->foo == NULL) {
        foo->foo = (struct foo *)malloc(sizeof(*foo));
        foo->foo->foo = NULL;
        foo->foo->bar = ++i;
        goto foo;
    }

    printf("The foo loop executed %d times\n", foo->foo->bar);
    return(EXIT_SUCCESS);
}

See Also

C language
ANSI Standard, §3.1.2.3

Notes

Pre-ANSI  implementations disagree  on the  name spaces  of structure/union
members.   The Standard  adopted the ``Berkeley''  rules, which  state that
every unique  structure/union type has its own name  space for its members.
It rejected the  rules of the first edition of  The C Programming Language,
which  state that  the members  of all  structures and  unions reside  in a
common name space.

© 2012 by Stephen A. Ness