63 The world of names — four name spaces and three axes

typedef struct node node;

63.1 The truth behind “C has no name spaces”#

The saying is widespread, and it misleads just as widely. The standard’s own sentence says nearly the opposite.

Section 6.2.3 states that if more than one declaration of a particular identifier is visible at a point in a translation unit, the syntactic context tells the uses apart; thus there are separate name spaces for the various categories of identifiers.

So C does have name spaces. What it lacks is the ability to open a new yard (this chapter calls each name space a yard where names live), as namespace app { … } does. Blur that distinction and you cannot explain why both of the following are true.

• typedef struct node node; is legal — different name spaces.
• Two libraries that each export a function called init break the link — the same name space.

63.2 The four name spaces#

Three points are worth fixing in mind.

• Members have a yard per type. The x of struct point and the x of struct vec have nothing to do with one another. That is why member names can stay short however many structs there are.
• There is one tag yard. struct, union and enum share it between the three of them. So if enum status exists, struct status cannot be made.
• Enumeration constants live in 4, not with the tags. This is where practice stubs its toe most often.

/* The same spelling x placed in all four name spaces at once — §6.2.3.
   It is legal and it compiles. Whether it reads well is another matter. */
#include <stdio.h>

/* (2) the tag name space — the name that follows struct/union/enum */
struct x {
    int x;        /* (3) the member name space — a yard of struct x's own */
    int y;
};

/* Another struct's members are another yard, so the spelling may recur */
struct point { int x; int y; };

/* (4) ordinary identifiers — variables, functions, typedef names and
      enumeration constants all live here. Same spelling as the tag x,
      different name space, so they coexist. */
typedef struct x x;

static int show(x v, struct point p)
{
    /* (1) the label name space — goto's target. This may be called x too */
    if (v.x < 0) goto x;

    printf("struct x    : x=%d y=%d\n", v.x, v.y);
    printf("struct point: x=%d y=%d\n", p.x, p.y);
    return 0;

x:  /* the label x */
    puts("negative, so we came to the label x");
    return 1;
}

int main(void)
{
    /* With one x in each of the four name spaces, use them all */
    x       a = { .x = 10, .y = 20 };   /* the typedef name x */
    struct x b = { .x = -1, .y = 0 };   /* the tag x */
    struct point p = { .x = 3, .y = 4 };

    puts("[the same spelling x lives in all four name spaces at once]");
    puts("  (1) label x  (2) tag struct x  (3) member x  (4) typedef name x");
    puts("");

    (void)show(a, p);
    (void)show(b, p);

    /* The syntactic context picks the name space:
       after struct -> tag, after . -> member, after goto -> label,
       anywhere else -> ordinary identifier. */
    printf("\nsizeof(x) = %zu, sizeof(struct x) = %zu  (the same type)\n",
           sizeof(x), sizeof(struct x));
    return 0;
}

[the same spelling x lives in all four name spaces at once]
  (1) label x  (2) tag struct x  (3) member x  (4) typedef name x

struct x    : x=10 y=20
struct point: x=3 y=4
negative, so we came to the label x

sizeof(x) = 8, sizeof(struct x) = 8  (the same type)

The same spelling x can live in all four yards at once and still compile and run, because the compiler picks which yard to search by syntactic context — after goto a label, after struct a tag, after . a member, elsewhere an ordinary identifier.

This is not, of course, an invitation to write that way. What the language allows and what a person can read are different ranges, and this listing goes to the extreme deliberately to show the first.

#define max 100
struct max { int x; };     // after struct, yet replaced by 100 → error

63.3 Three axes — scope, linkage, name space#

Now put the three side by side. They confuse people because all three attach to the same name at once while each answers a different question.

The three answer different questions — so each must be asked separately. They are not independent, though. Where a declaration sits settles both its scope and its linkage: move a file-scope int n; into a block and its scope goes from file to block while its linkage goes from external to none. And tags, members and labels never have linkage. One example reads the three apart: a file-scope struct node tag is “file scope + no linkage (tags have none) + tag name space”, while its member next is “file scope + no linkage + member name space”. The two share scope and linkage and differ only in name space — that next is looked up only after . or -> is the third axis’s doing.

63.4 A habit born of tags living apart#

That tags and ordinary identifiers are different yards has shaped how C code looks.

/* Where tag and typedef part ways, and the collision that arises because
   enumeration constants are ordinary identifiers. */
#include <stdio.h>

/* The tag name space and the ordinary-identifier name space differ, so the
   same spelling can name both a tag and a typedef */
typedef struct node {
    int          value;
    struct node *next;      /* the tag is what lets it point at itself */
} node;

/* Enumeration constants are ordinary identifiers, not tags.
   So red below lives in the same yard as an int variable red — they clash. */
enum color { red, green, blue };

/* Written out, this is a compile error (shown only as a comment):
       int red;        // error: 'red' redeclared as different kind of symbol
   Which is why practice puts a prefix on enumeration constants. */
enum status { STATUS_OK, STATUS_BUSY, STATUS_FAIL };

/* Conversely a tag never clashes with an ordinary identifier.
   But struct/union/enum *share one tag yard between them* — so
       struct status { int code; };
   clashes with the enum status above ("defined as wrong kind of tag").
   There is one tag name space, not one per keyword. */
struct handle { int code; };     /* use a different spelling */

/* The ordinary-identifier yard, though, is wholly separate from the tag one */
static int status = 42;          /* coexists with the enum status tag */

static const char *name_of(enum color c)
{
    switch (c) {
    case red:   return "red";
    case green: return "green";
    case blue:  return "blue";
    }
    return "?";
}

int main(void)
{
    node b = { .value = 2, .next = nullptr };
    node a = { .value = 1, .next = &b };

    puts("[tag and typedef name are different name spaces, so one spelling serves]");
    for (node *p = &a; p; p = p->next)
        printf("  node %d\n", p->value);

    puts("\n[enumeration constants are ordinary identifiers — the variables' yard]");
    printf("  enum color: %s %s %s\n", name_of(red), name_of(green), name_of(blue));
    puts("  so int red; is a compile error — hence the STATUS_OK prefix habit");

    puts("\n[struct, union and enum share the tag yard — there is only one]");
    struct handle h = { .code = 7 };
    enum   status e = STATUS_BUSY;
    printf("  struct handle.code = %d, enum status = %d\n", h.code, (int)e);
    puts("  struct status is impossible — enum status already took that tag");

    puts("\n[but ordinary identifiers sit in a different yard from tags]");
    printf("  the variable status = %d lives beside the tag status\n", status);
    return 0;
}

[tag and typedef name are different name spaces, so one spelling serves]
  node 1
  node 2

[enumeration constants are ordinary identifiers — the variables' yard]
  enum color: red green blue
  so int red; is a compile error — hence the STATUS_OK prefix habit

[struct, union and enum share the tag yard — there is only one]
  struct handle.code = 7, enum status = 1
  struct status is impossible — enum status already took that tag

[but ordinary identifiers sit in a different yard from tags]
  the variable status = 42 lives beside the tag status

63.4.1 typedef struct node node;#

The commonest idiom. The tag node and the typedef name node are in different yards, so the same spelling serves both, and code using the type need not write struct every time. Notice too that a pointer to itself requires the tag — at the point struct node *next; is written, the typedef name is not yet complete.

63.4.2 And yet there are conventions that forbid typedef#

The Linux kernel’s coding style is the well-known one. Its objection is the concealment of information — node n; alone does not say whether that is a struct, a pointer or an integer, whereas struct node n; says so on sight. Where large code is read by many, that information is worth more than a few keystrokes.

Which of the three is right is not settled. Settling on one and keeping it is.

63.5 Enumeration constants are ordinary identifiers#

Write enum color { red, green, blue }; and red, green and blue go not into the tag yard but into yard 4 — the same yard as variables and functions.

enum color { red, green, blue };
int red;                 // error: 'red' redeclared as different kind of symbol

Hence practice’s convention of prefixing enumeration constants — STATUS_OK, GTK_ALIGN_FILL, SDL_QUIT. The names look long, but in a world where variables, functions and enumeration constants share one yard that prefix is the fence.

63.6 Shadowing#

Declare the same spelling again in an inner scope and the outer one is shadowed. It is legal, occasionally useful, and often the site of an accident.

int count = 1;                    // global
static int f(int count) {         // the parameter shadows the global
    { int x = count; { int x = 2; return x; } }   // inner x shadows outer x
}

The trouble is that the warning is not on by default.

for (int i = 0; i < n; i++) {
    for (int i = 0; i < m; i++) { /* the outer i is lost */ }
}

63.7 Names you must not use — names reserved for the standard and the implementation#

In a world with only four name spaces, the standard library and the implementation reserved space in advance. Trespass and it may work today and break in the next version.

The ground is §7.1.3, and the fuller story returns in chapter 97.

★ C23 drew one more mark here — the potentially reserved identifier. Names the standard describes as optional (an implementation may or may not provide them) are not reserved until provided, but sit where an implementation or a future edition may take them at any time. Before C23 the line between reserved and not was blurred and easy to slip past into undefined behaviour; naming the case split it cleanly.

The practical meaning is one sentence — such a name may work today and not tomorrow. The standard even encourages implementations to diagnose their use (§7.1.3).

We know the rules for names. Yet keep every rule and two libraries exporting the same spelling still collide — there is no way to dig a new yard in C. That is the next chapter’s problem: how collisions are prevented, and how C++ solved it.