40 Arrays and pointers — when they are the same and when they are not

40.1 Why this chapter has to exist

Let us first say why this chapter remains after the previous two. Not one piece of new syntax appears in it. What it does is gather what has already been learned into one place and close it as rules. Is that worth doing?

It is. Because “an array is a pointer” is the most widespread misunderstanding in C, and at the same time the one discovered latest.

40.1.1 Why the misunderstanding is so tough

For a false sentence to spread it has to be true often. This one is exactly that.

char buf[64];
char *p = buf;

strlen(buf);        /* works */
strlen(p);          /* works */
printf("%s %s", buf, p);   /* both work */
buf[3];  p[3];      /* both work */

People learning C generally go in this order — write everything inside one function, then split into functions, and only at the end split into files. ★ Most of that road is spent in the one context where arrays and pointers really are interchangeable, because that context is the function argument. So hundreds of successes pile up before the first wrong place is ever met.

There is one more reason the two look identical to us. We have always seen main’s parameter written char *argv[] or char **argv at whim. That too works because it is a function parameter, but the context is invisible, and a false confidence grows: “C is consistent and regular about address arithmetic.”¹

40.1.2 And discovery comes late

Inside one file the compiler catches it. Use as a pointer something defined as an array and the types disagree, so it is an error at once. The trouble is when the files differ. Then the compiler cannot see both sides at once. §4 confirms it for real; here is the conclusion in advance — it compiles, it links, and it dies when it runs.

40.2 What differs — five axes

Put the two side by side and split them axis by axis.

The third axis is especially interesting. Write int a[5]; and those twenty bytes carry the name a. Write int *p = malloc(20); and those twenty bytes have no name — the name p belongs to the eight bytes holding an address, not to the twenty bytes of data. Chapter 44′s point that things on the heap are nameless meets us again here.

/* 배열과 포인터가 어디서 갈라지는지를 한자리에서 갈라 본다.
   같은 자리를 가리키는 두 값이 어떻게 다르게 행동하는지가 요점이다. */
#include <stdio.h>

static int  arr[5] = { 10, 20, 30, 40, 50 };
static int *ptr    = arr;          /* 무너진 주소를 담는다 */

static void by_param(int p[5])     /* [5] 라고 적어도 포인터다 */
{
    /* 오늘의 컴파일러는 바로 이 자리에 경고를 준다(-Wsizeof-array-argument).
       경고가 맞다 — 보여 주기 위해 그 하나만 잠시 끈다. */
#if defined(__GNUC__)
#  pragma GCC diagnostic push
#  pragma GCC diagnostic ignored "-Wsizeof-array-argument"
#endif
    printf("  inside the function sizeof p = %zu  (one pointer)\n", sizeof p);
#if defined(__GNUC__)
#  pragma GCC diagnostic pop
#endif
}

int main(void)
{
    puts("① what does it hold - the size tells you");
    printf("  sizeof arr = %zu   sizeof ptr = %zu\n", sizeof arr, sizeof ptr);
    printf("  element count: sizeof arr / sizeof arr[0] = %zu\n",
           sizeof arr / sizeof arr[0]);

    puts("\n② same address, different type - +1 skips a different width");
    printf("  arr      = %p\n", (void *)arr);
    printf("  &arr[0]  = %p   (the same)\n", (void *)&arr[0]);
    printf("  &arr     = %p   (the same - but its type is int(*)[5])\n", (void *)&arr);
    printf("  arr  + 1 = %p   (+%td bytes)\n",
           (void *)(arr + 1), (char *)(arr + 1) - (char *)arr);
    printf("  &arr + 1 = %p   (+%td bytes - it skips the whole array)\n",
           (void *)(&arr + 1), (char *)(&arr + 1) - (char *)arr);

    puts("\n③ which one can move");
    ptr = ptr + 2;                 /* 포인터는 옮길 수 있다 */
    printf("  moving ptr two slots gives *ptr = %d\n", *ptr);
    /* arr = ptr;  <- 배열 이름은 수정 가능한 좌변값이 아니다: 컴파일 오류 */
    ptr = arr;

    puts("\n④ a subscript is a pointer offset - which is why it can be reversed");
    printf("  arr[3] = %d,  *(arr + 3) = %d,  3[arr] = %d\n",
           arr[3], *(arr + 3), 3[arr]);

    puts("\n⑤ pass it to a function and the size disappears");
    printf("  sizeof arr before the call = %zu\n", sizeof arr);
    by_param(arr);

    return 0;
}

① what does it hold - the size tells you
  sizeof arr = 20   sizeof ptr = 8
  element count: sizeof arr / sizeof arr[0] = 5

② same address, different type - +1 skips a different width
  arr      = 0x55fdd1f76020
  &arr[0]  = 0x55fdd1f76020   (the same)
  &arr     = 0x55fdd1f76020   (the same - but its type is int(*)[5])
  arr  + 1 = 0x55fdd1f76024   (+4 bytes)
  &arr + 1 = 0x55fdd1f76034   (+20 bytes - it skips the whole array)

③ which one can move
  moving ptr two slots gives *ptr = 30

④ a subscript is a pointer offset - which is why it can be reversed
  arr[3] = 40,  *(arr + 3) = 40,  3[arr] = 40

⑤ pass it to a function and the size disappears
  sizeof arr before the call = 20
  inside the function sizeof p = 8  (one pointer)

Output ① is the first and fourth axes. sizeof arr is 20 and sizeof ptr is 8. Two values naming the same place answer differently when asked their own size.

② is the most valuable part. arr, &arr[0] and &arr are all the same address. Yet add 1 and they split.

• arr + 1 — one int over, +4 bytes
• &arr + 1 — the whole array over, +20 bytes

★ Same address, different type, different value. arr decayed into int *; &arr did not decay and is int (*)[5]. The declaration reading of chapter 59 pays here — read the two type names and you can see the difference.

③ is another face of the third axis. ptr can move; arr cannot. arr = ptr; is a compile error, because an array name is not a modifiable lvalue. The example leaves it in a comment.

40.3 Steps to reach it — this is the real difference

The second of the five axes is the most fundamental. And you can see it. The very same x[i] is translated into different machine code for an array and for a pointer.

extern int  a[];
extern int *p;
int via_array(int i)   { return a[i]; }
int via_pointer(int i) { return p[i]; }

Compiled with gcc -O2 -c and looked at with objdump -d (x86-64).

★ The difference shows up as one instruction. The array side ends with a lea (address computation); in that same slot the pointer side has a mov — a read that fetches the pointer value out of memory. The array side has no such read at all, because the array’s address is fixed at compile time.

Two things follow.

First, why both extern char a[]; and extern char a[100]; work. The compiler only needs to make offsets from the start, so it need not know the total length. The dimensions other than the outermost, though, it must know — that is how it decides how many bytes to step (the rule from chapter 39).

Second, why the folklore says pointers beat arrays. It used to be held that a subscript inside a loop costs a multiply each time, so stepping a pointer is faster. ★ Today that folklore is mostly wrong. Subscripting is defined in terms of pointers, so an optimiser commonly turns the two into the same form; and the array side often carries clearer aliasing information, which helps vectorisation.

40.4 The accident that crosses a file

Now the place §1 promised. The definition is an array; the declaration says pointer.

/* def.c */  char msg[16] = "ABCDEFGHIJKLMNO";
/* use.c */  extern char *msg;      /* <- a lie */
             printf("%c", msg[0]);

We compiled the two files separately, linked and ran them.

What happened. use.c believes that an address lives at the place called msg. So it reads eight bytes there and uses them as an address. But what those eight bytes actually contain are the characters 'A'~'H'. Read little-endian they make the number 0x4847464544434241, and going to that address kills the program.

★ Be precise about what is at fault here. The compiler did nothing wrong: looking at use.c alone, that code is perfectly right, and the linker joins names without knowing types. What was wrong was the promise a human made.

/* written out in each file that uses them */
extern char *msg;
extern int   count;

/* msg.h */  extern char msg[16];
/* def.c */  #include "msg.h"     <- the defining side includes it too. This line is the point
             char msg[16] = "...";

40.5 When they do become the same — three rules

Now the other direction. Close the places where decay does happen, as rules, with the standard’s clauses.

What matters is where each rule is used.

Rule ① is what makes int *p = arr; legal, and why strlen(buf) works.

Rule ② is not notation but definition. So a[i] and *(a+i) are not “the same result” but “the same thing”. §7 shows an amusing consequence.

Rule ③ is the most often misread. It happens in the one context of a function parameter and nowhere else. Everywhere else an array declaration is an array declaration and a pointer declaration is a pointer declaration — §4′s accident is exactly what happens when that is not known.

40.6 The places that do not decay

Rule ① has exceptions, and they matter enormously in practice. Knowing where decay does not happen is knowing what an array really is.

The last row is especially important. Two lines that look almost the same do entirely different things.

char a[] = "gooseberry";   /* an array - mine, so I may change it */
char *p  = "breadfruit";   /* merely points at a literal - changing it is undefined */

a is my own array made by copying the literal’s contents. p merely points at a literal living somewhere in the program. So a[0] = 'G'; is fine and p[0] = 'B'; is undefined behaviour — usually placed in a read-only region and killed at run time (chapter 41).

void f(int a[10]) {
    size_t n = sizeof a / sizeof a[0];   /* 2, not 10 */
}

40.7 Why 6[a] is legal

Accept rule ② as a definition and an amusing consequence follows. If a[i] is *(a + i), then since addition commutes *(i + a) is the same thing, and hence so is i[a].

Output ④ confirmed it — arr[3], *(arr + 3) and 3[arr] are all 40.

There is no occasion to write this in real code. But it is worth knowing, because the very legality of the notation proves that the subscript is the syntax of pointers, not of arrays. Had [] been an array-only device, 3[arr] would have been nonsense.

40.8 Parameter conversion happens one layer only

This is where people most often go wrong extending rule ③ to more dimensions. ★ An array of arrays does not become a “pointer to pointer”. It becomes a “pointer to array”.

/* 매개변수에서 배열이 포인터로 고쳐지는 규칙은 「한 겹만」 적용된다.
   그리고 C99 이후에는 크기를 함께 넘겨 진짜 2차원 매개변수를 쓸 수 있다. */
#include <stdio.h>

/* ① 배열의 배열 → 「배열에 대한 포인터」  (포인터의 포인터가 아니다) */
static void take_2d(int (*m)[3], size_t rows)
{
    printf("  int m[][3]  → int (*m)[3] : sizeof m = %zu, sizeof *m = %zu\n",
           sizeof m, sizeof *m);
    printf("  m[1][2] = %d   (one row is %zu bytes)\n", m[1][2], sizeof *m);
    (void)rows;
}

/* ② 포인터의 배열 → 「포인터에 대한 포인터」  (argv 가 이 모양이다) */
static void take_argvish(char **v)
{
    printf("  char *v[]   → char **v   : v[0]=\"%s\", v[1]=\"%s\"\n", v[0], v[1]);
}

/* ③ C99 이후 — 크기를 먼저 받으면 진짜 가변 2차원 매개변수가 된다 */
static long sum_2d(size_t rows, size_t cols, int m[rows][cols])
{
    long s = 0;
    for (size_t i = 0; i < rows; i++)
        for (size_t j = 0; j < cols; j++)
            s += m[i][j];
    return s;
}

int main(void)
{
    int  grid[2][3] = { { 1, 2, 3 }, { 4, 5, 6 } };
    int  wide[2][4] = { { 1, 1, 1, 1 }, { 2, 2, 2, 2 } };
    char *names[]   = { "hana", "dul" };

    puts("① passing an array of arrays");
    take_2d(grid, 2);

    puts("\n② passing an array of pointers");
    take_argvish(names);

    puts("\n③ pass the sizes too and one function takes any width");
    printf("  sum_2d(2,3,grid) = %ld\n", sum_2d(2, 3, grid));
    printf("  sum_2d(2,4,wide) = %ld   <- a shape take_2d cannot accept\n",
           sum_2d(2, 4, wide));

    return 0;
}

① passing an array of arrays
  int m[][3]  → int (*m)[3] : sizeof m = 8, sizeof *m = 12
  m[1][2] = 6   (one row is 12 bytes)

② passing an array of pointers
  char *v[]   → char **v   : v[0]="hana", v[1]="dul"

③ pass the sizes too and one function takes any width
  sum_2d(2,3,grid) = 21
  sum_2d(2,4,wide) = 12   <- a shape take_2d cannot accept

Put the first two rows side by side and the rule is plain. Only the outermost layer becomes a pointer; the inside is untouched. Output ① is the proof — sizeof m is 8 (a pointer) while sizeof *m is 12, a row of three ints.

★ Now a long-standing puzzle resolves. Why is main’s second parameter char **argv? Because argv is an array of pointers (the second row). Had it been an array of arrays it would have become something like char (*argv)[15]. Output ② mimics exactly that shape.

40.9 So what C cannot do — and the half-told rest

Knowing all the rules above, one of C’s old limits emerges as a logical consequence.

There was (for a long time) no general way to pass a multidimensional array of arbitrary size to a function. The reason is exactly what §8 showed: the parameter becomes a “pointer to array”, and to fix how far one step of that pointer moves, the inner dimension must be known at compile time.

So the function below accepts only arrays exactly three wide.

void take_2d(int (*m)[3], size_t rows);   /* [2][3] and [999][3] are fine */
                                          /* [2][4] is not */

People have dodged this wall three ways, and all three cost something.

40.9.1 What C99 changed

★ In 1999 the wall was partly torn down. Take the sizes as earlier parameters and you may use those names as dimensions in the parameters that follow.

long sum_2d(size_t rows, size_t cols, int m[rows][cols]);

Output ③ runs exactly this. One function takes [2][3] and [2][4] alike — impossible with take_2d. The inner dimension being known at run time, the compiler emits the right index arithmetic for you. You keep flattening’s benefit (contiguous memory) and lose its danger.

40.10 Choosing between them — judgement in practice

We have closed the relation between arrays and pointers into rules. The next chapter builds loops on top of that relation — nested loops, how to get out of them, and making a block for a macro.