COHERENT manpages
This page displays the COHERENT manpage for name space [C name-space rules].
List of available manpages
Index
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.