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

typedef struct node node;

55.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, 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.

55.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.

/* 같은 철자 x 를 네 이름 공간에 동시에 둔다 — 표준 §6.2.3.
   합법이고 컴파일된다. 읽기 좋은가는 별개의 문제다. */
#include <stdio.h>

/* ② 태그 이름 공간 — struct/union/enum 뒤에 오는 이름 */
struct x {
    int x;        /* ③ 멤버 이름 공간 — struct x 만의 마당 */
    int y;
};

/* 다른 구조체의 멤버는 또 다른 마당이라 같은 철자를 다시 써도 된다 */
struct point { int x; int y; };

/* ④ 보통 식별자 — 변수·함수·typedef 이름·열거 상수가 모두 여기에 산다.
      태그 x 와 철자가 같지만 다른 이름 공간이라 공존한다. */
typedef struct x x;

static int show(x v, struct point p)
{
    /* ① 레이블 이름 공간 — goto 의 표적. 이것도 x 라 지을 수 있다 */
    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:  /* 레이블 x */
    puts("negative, so we came to label x");
    return 1;
}

int main(void)
{
    /* 네 이름 공간에 x 가 하나씩 있는 상태에서 전부 쓴다 */
    x       a = { .x = 10, .y = 20 };   /* typedef 이름 x */
    struct x b = { .x = -1, .y = 0 };   /* 태그 x */
    struct point p = { .x = 3, .y = 4 };

    puts("[the same spelling x lives in four name spaces at once]");
    puts("  ① label x   ② tag struct x   ③ member x   ④ typedef name x");
    puts("");

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

    /* 이름을 찾는 자리(문법적 문맥)가 이름 공간을 고른다.
       struct 뒤 → 태그, . 뒤 → 멤버, goto 뒤 → 레이블, 그 밖 → 보통 식별자. */
    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 four name spaces at once]
  ① label x   ② tag struct x   ③ member x   ④ typedef name x

struct x  : x=10 y=20
struct point: x=3 y=4
negative, so we came to 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

55.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 remaining independent of one another.

One line confirms that the three are orthogonal — a file-scope struct node tag is “file scope + no linkage (tags have none) + tag name space”, while its member next is “visible only inside that struct + no linkage + member name space”.

55.4 A habit born of tags living apart

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

/* 태그와 typedef 가 갈리는 자리, 그리고 열거 상수가 '보통 식별자'라서
   생기는 충돌. */
#include <stdio.h>

/* 태그 이름 공간과 보통 식별자 이름 공간이 달라서
   "같은 철자"로 태그와 typedef 이름을 둘 다 만들 수 있다 */
typedef struct node {
    int          value;
    struct node *next;      /* 태그가 있어야 자기 자신을 가리킬 수 있다 */
} node;

/* 열거 상수는 태그가 아니라 *보통 식별자* 다.
   그래서 아래 red 는 int 변수 red 와 같은 마당에 산다 — 충돌한다. */
enum color { red, green, blue };

/* 이렇게 쓰면 컴파일 오류다(주석으로만 보인다):
       int red;        // error: 'red' redeclared as different kind of symbol
   그래서 실무는 열거 상수에 접두어를 붙인다. */
enum status { STATUS_OK, STATUS_BUSY, STATUS_FAIL };

/* 반대로 태그는 보통 식별자와 절대 충돌하지 않는다.
   단, struct/union/enum 은 태그 마당을 *셋이서 함께 쓴다* — 그래서
       struct status { int code; };
   는 위의 enum status 와 충돌한다("defined as wrong kind of tag").
   태그 마당은 넷 중 하나이지, 키워드마다 하나가 아니다. */
struct handle { int code; };     /* 다른 철자를 쓴다 */

/* 반면 보통 식별자 마당은 태그와 완전히 별개다 — 같은 철자를 써도 된다 */
static int status = 42;          /* enum status 태그와 공존한다 */

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("[tags and typedef names are different name spaces, so the spelling can be shared]");
    for (node *p = &a; p; p = p->next)
        printf("  node %d\n", p->value);

    puts("\n[enumeration constants are ordinary identifiers - the same space as variables]");
    printf("  enum color: %s %s %s\n", name_of(red), name_of(green), name_of(blue));
    puts("  which is why int red; is a compile error - hence the habit of prefixes (STATUS_OK)");

    puts("\n[struct, union and enum share one tag space - 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("  you cannot declare struct status - enum status already took that tag");

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

[tags and typedef names are different name spaces, so the spelling can be shared]
  node 1
  node 2

[enumeration constants are ordinary identifiers - the same space as variables]
  enum color: red green blue
  which is why int red; is a compile error - hence the habit of prefixes (STATUS_OK)

[struct, union and enum share one tag space - there is only one]
  struct handle.code = 7, enum status = 1
  you cannot declare struct status - enum status already took that tag

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

55.4.1 typedef struct node node;

The commonest idiom. The tag node and the typedef name node are different yards, so the same spelling serves both, and the caller 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.

55.4.2 And yet there are conventions that forbid typedef

The Linux kernel’s coding style is the well-known one. Its ground is 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.

55.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 with one yard that prefix is the fence.

55.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 */ }
}

55.7 Names you must not use — the reserved yard

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 82.

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 this spot.