36 Objects, addresses, pointers

36.1 Three words first — object, address, pointer#

This chapter’s title is three words. We have passed all three many times already — “address” as chapter 3′s locker number, “object” whenever the standard was quoted, “pointer” as a promise of “later”. But none of them has ever been defined. Learn the syntax (* and &) first and the symbols soon come easily to the hand, while what they handle stays blurred. A good part of the pointer’s reputation for difficulty actually comes from that blur.

So this chapter changes the order. We define the three words one at a time, in the sense the standard uses, draw them, check them with a small program, and only then move to the syntax. There is no need to hurry. Get through this section properly and the remaining ten chapters of this part become a good deal easier.

No need to memorise the table. We unfold it line by line below.

36.1.1 Object — a region of memory that holds a value#

The standard defines an object like this.

object: region of data storage in the execution environment, the contents of which can represent values.
(Note: when referenced, an object can be interpreted as having a particular type.)
— C23 §3.15

There is not one hard word in it, and yet it does not land at once. Cut it into three pieces.

• “Region of data storage” — a place in memory. In chapter 3′s locker corridor it is a run of adjacent lockers, one or more. One int takes four lockers (4 bytes) on this book’s machine, one double takes eight.
• “In the execution environment” — it exists while the program runs. Not the letters in the source code, but a place really set up in memory when the program runs.
• “The contents of which can represent values” — the bits in those lockers can be read as some value. The 32 bits in four lockers read as the integer 55, say.

The note matters too. The bits in a locker mean nothing by themselves (chapter 3 — “what knows about the lump is the side doing the reading”). Read the same four lockers as an int and you get an integer; read them as a float and you get a real number. What an object is read as is decided by the type of the expression that reaches it. Later this note becomes the answer to why pointer types are needed.

So when you write int n = 55;, this is what happens. A four-byte region is set up in memory, bits representing 55 are put in it, and the region is given the name n. That region is the object. Picture it placed at address 200 on this book’s machine (a little-endian x86-64).

Figure 36.1 — The object n — four lockers from address 200, holding 55 (hex 37) in little-endian order

The four boxes with heavy borders are one object. Each box is a byte, and the four together make one int object. (Address 200 was chosen for the picture. The real address changes from run to run — a question later in this chapter shows why.)

36.1.2 What is an object and what is not#

With the definition in hand, let us sort out what is an object and what is not. A few are surprising at first.

Two things deserve a look.

First, an object need not have a name. String literals and malloc’s regions exist without one. With no name they can be reached only by their address, and what holds that address is the pointer. Without pointers there would be no way to touch a nameless object — the shortest answer to why pointers are needed.

Second, a value and an object are different. 3 is a value, not an object. n is an object, and right now it may hold 3. It is the relation of a box to the thing in the box. Blur it and meaningless questions appear, such as “what is the address of 3?” — there is no place holding it, so there is no address.

36.1.3 What every object has#

Some things always come with an object. The eleven chapters of this part are, in effect, chapters that dig into this list one item at a time.

Remember the last row in particular, lifetime. Objects do not last forever. A variable inside a function disappears when that function ends. A pointer still holding the place of a vanished object is one of C’s famous accidents, and its story is told in chapter 45.

36.1.4 A value or a place — the lvalue view#

Read n = n + 1; slowly. The same n appears twice and does different work.

• The n on the right is a value. “Fetch the number now in n.” One is added to it.
• The n on the left is a place. “Put it into the region called n.” What it holds is of no interest.

The standard has a name for this distinction. An expression that can designate an object is called an lvalue (§6.3.2.1p1) — the word met once in chapter 35, on the left of an assignment. n is an lvalue. So is a[1]. But n + 1 is not — it is just a computed value and designates no region. So n + 1 = 5; is a compile error: there is no place to put anything.

Then how does the n on the right become a value? The standard’s rule: in most places an lvalue is automatically turned into “the value held in that object” (the same clause, p2: lvalue conversion). There are a few places where it is not turned — the left of an assignment, the operand of ++ and --, the operand of sizeof, and the operand of &, which we are about to meet. In those contexts an expression stays a “place” rather than a “value”.

The other side — what is used as a value, like the n on the right, and what is nothing but a value from the start, like n + 1 — is commonly called an rvalue. But that word is customary usage. The standard only notes in a footnote that “what is sometimes called ‘rvalue’ is in this document described as the ‘value of an expression’” (§6.3.2.1, footnote) and does not use the word itself. The two names come from the left and right of an assignment, but the meaning matters more than the names — an lvalue is an expression that designates a place; an rvalue is just a value. (Some lvalues cannot stand on the left of an assignment, such as a const variable — the “modifiable lvalue” of chapter 52.)

That gives the next section’s conclusion in advance. & is an operator that asks for a place, so it can be used only on things that have one (lvalues). &n works; &3 and &(n + 1) do not.

36.1.5 Address — where an object sits#

Memory is a long line of bytes, each with a number (chapter 3). The standard has the same picture: it defines the byte as an “addressable unit of data storage” and notes that the address of each individual byte of an object can be expressed uniquely (§3.6).

Then what is an object’s address? An object spans several bytes, but it has one address. The answer is its first byte, the one with the lowest address. The n above occupies lockers 200, 201, 202 and 203, and n’s address is 200. The standard says the same: convert a pointer to an object into a character pointer and “the result points to the lowest addressed byte of the object” (§6.3.2.3p7).

An important question arises here. Address 200 alone does not tell you the whole object. Is what starts at 200 a 1-byte char, a 4-byte int, an 8-byte double? The address gives only the starting point; it says nothing about how many lockers to read, or how. The definition’s note — “interpreted as having a particular type” — comes back here. Only when a type comes with the address can the object at that place be read.

C ties the pair together from the start. Look at the definition of the unary & operator.

The unary & operator yields the address of its operand. If the operand has type “type”, the result has type “pointer to type”.
— C23 §6.5.4.2

So &n is not the bare number 200. It is the value “there is an int at address 200”, and the type of that value is int *. In C the way to get hold of an address always goes through a value with a type attached. From here on, when this book says “address” it means the number at the machine’s level, and when it says “pointer value” it means that number with a type (and, as chapter 38 shows, a provenance) attached — a value at the language’s level.

36.1.6 Pointer — holding an address as a value#

Now the last word. The standard defines the pointer as a type.

A pointer type may be derived from a function type or an object type, called the referenced type. A pointer type describes an object whose value provides a reference to an entity of the referenced type.
— C23 §6.2.5

In plain words: there is a type “pointer to int”, and the value held in an object of that type refers to some int. From the type int a new type int * is derived — from double, double *; from char, char *.

Here is the thing that confuses beginners most. The single word “pointer” means three things.

“p is a pointer” usually means the third; “&n is a pointer” means the second. The context usually tells them apart, but when confused, come back to this table and ask: “is this about a type, a value, or the box holding the value?”

And here is the most important sentence of this section. A pointer variable is an object too. Like any other variable it has its own region in memory, a size (8 bytes on this book’s machine) and its own address. It is just that the value in that region is the address of another object. After int *p = &n; memory looks like this (say p sits at address 208).

Figure 36.2 — The object p — eight lockers from address 208. The value held is 200 (hex C8): n’s address

Put it beside the picture of n. Address 200 holds the value 55, and address 208 holds the value 200. Both are just bits, and both are just objects. The only difference is the eye that reads them — since p’s type is int *, C reads those eight bytes as “the place where an int sits”. That is all “p points at n” means: the value held in p is n’s address, and there is no mystery beyond that.

In chapter 3′s locker picture it comes out neatly.

• n is four lockers in a row from number 200, holding 55.
• &n is a slip reading “locker 200, an int is there”.
• p is another locker (eight of them from 208) where that slip is kept.
• *p means “take out the slip in p, read it, and go to the locker written on it”.

The slip sits in some locker too, so that locker has a number as well, and a slip can be made with that number on it — &p, whose type is int ** (“pointer to int *”). A pointer to a pointer sounds dizzying at first, but think of it as a slip bearing the number of the locker where a slip is kept and there is nothing strange about it.

36.1.7 The three words at once — a demonstration#

Definitions in words fade quickly. Check them one at a time with a small program. It does not print addresses themselves (they change from run to run — a question later in this chapter covers that). It prints sizes, equalities and changes of value instead.

#include <stdio.h>

int main(void)
{
    int n = 55;                 /* one object: name n, value 55 */
    int *p = &n;                /* another object: value n's address */

    puts("[1] every object has a size");
    printf("sizeof n = %zu bytes\n", sizeof n);
    printf("sizeof p = %zu bytes\n", sizeof p);

    puts("\n[2] p holds n's address; p itself lives somewhere else");
    printf("p  == &n : %d\n", p == &n);
    printf("&p == &n : %d\n", (void *)&p == (void *)&n); /* two objects */

    puts("\n[3] two roads to one object: the name n and *p");
    *p = 77;                    /* go to the address written in p and write */
    printf("after *p = 77 : n  = %d\n", n);
    n = 99;                     /* write by the name --- the same object */
    printf("after n = 99  : *p = %d\n", *p);

    puts("\n[4] a pointer is a variable: it can be pointed elsewhere");
    int m = 1;
    p = &m;                     /* now p points at m */
    *p = 2;
    printf("after p = &m; *p = 2 : n = %d, m = %d\n", n, m);

    puts("\n[5] a pointer is an object too, so it has an address");
    int **pp = &p;              /* a pointer to "a pointer to int" */
    **pp = 3;                   /* pp → p → m */
    printf("after **pp = 3 : m = %d\n", m);
    return 0;
}

[1] every object has a size
sizeof n = 4 bytes
sizeof p = 8 bytes

[2] p holds n's address; p itself lives somewhere else
p  == &n : 1
&p == &n : 0

[3] two roads to one object: the name n and *p
after *p = 77 : n  = 77
after n = 99  : *p = 99

[4] a pointer is a variable: it can be pointed elsewhere
after p = &m; *p = 2 : n = 99, m = 2

[5] a pointer is an object too, so it has an address
after **pp = 3 : m = 3

Read the five pieces in turn.

[1] Every object has a size. n is 4 bytes, p is 8. Notice that a pointer variable can be larger than what it points at — p’s size is not “the size of what it points at” but “the size needed to hold an address”. (That this 8 is not always 8 is a story at the end of this chapter.)

[2] p holds n’s address, and p itself is elsewhere. p == &n is 1 (true) — the value in p equals n’s address. &p == &n is 0 (false) — the locker holding the slip and the locker holding 55 are different lockers. (The two addresses have different types, so they were brought to void * before comparing; that conversion is explained later in this chapter.)

[3] Two roads to one object. Write with *p = 77 and read with n: 77. Write with n = 99 and read with *p: 99. The same object can be reached by name or by address, and both roads arrive at the same region. The essence of what a pointer does is in this one piece.

[4] A pointer is a variable. Put another address in p with p = &m, and *p now reaches m. The *p = 2 that follows changes m and leaves n alone (n is still 99). Rewrite the slip and the locker you go to changes.

[5] A pointer is an object too, so it has an address. pp holds p’s address. **pp means “follow pp’s slip to p, then follow p’s slip once more” — p now points at m, so m becomes 3.

In sum, three sentences. An object is a region of memory that holds a value. An address is where that region sits — the number of its first byte. A pointer handles that address as a value, together with a type, and a pointer variable is one more object holding that value. Now we see the syntax for writing these in C.

36.2 Three notations — declaration, &, *#

With the words settled, now the syntax. Pointer syntax is three pieces and no more.

Declaration — int *p; declares “a variable p holding the address of an int.” The trick is to read it from the back: “p is a pointer (*p), and at the place it points there is an int.”

Taking an address — &n is the value “n’s address.” The & brushed past in chapter 26′s sscanf(..., &n) finally gets its formal name — the operator that gives you the number tag of the locker called n.

Dereference — *p means “go to the address written in p and that slot.” When read, it fetches that slot’s value; on the left of an assignment it writes to that slot. That the * of a declaration, the * of an expression (dereference) and the * of multiplication use the same character is C’s notorious thrift — position is the only way to tell them apart.

The demonstration shows all three at once, including chapter 34′s homework — the proper method by which a function changes the caller’s original.

#include <stdio.h>

void set_to(int *target, int value)
{
    *target = value;            /* it follows the address and writes to the original */
}

int main(void)
{
    int n = 1;
    int *p = &n;                /* p holds the address of n */

    printf("n at first: %d\n", n);
    printf("p == &n ? %d\n", p == &n);

    *p = 55;                    /* dereference: write where p points (= n) */
    printf("n after *p = 55: %d\n", n);

    set_to(&n, 99);             /* chapter 34's homework — a function changes the original */
    printf("n after set_to: %d\n", n);
    return 0;
}

n at first: 1
p == &n ? 1
n after *p = 55: 55
n after set_to: 99

Read the route of set_to(&n, 99) exactly and you are halfway through pointers — ① &n (the value that is an address) is copied into the parameter target (chapter 34′s copy-by-value rule is untouched!), and ② inside the function *target = value goes to that address and writes into the original slot. The world of copying values was not broken at all — what was copied happened to be an address.

36.3 sizeof — asking the size of a container#

The last deferred credit — sizeof is the operator that yields the size in bytes of a type or an object (its value is of type size_t, an unsigned integer just for sizes, printed with %zu). Chapter 26′s fgets(line, sizeof line, stdin) now reads completely: “tell fgets the number of bytes in the container called line.” Being an operator rather than a function, its value is mostly settled at compile time, and it works on a type (sizeof(int)) as well as on an object (sizeof line).

36.3.1 The type sizeof yields — size_t#

That sizeof yields a size_t is not a footnote but a contract. Know this one type exactly and several traps in later chapters are closed off in advance.

★ What bites most often is that it has no sign. Set beside a signed integer, the usual arithmetic conversions pull the signed side up into the unsigned one (chapter 30) — so the following holds.

int n = -1;
if (n < sizeof arr) { … }     /* looks true, and is *false* */

This book checked it directly — the value of -1 < sizeof arr was 0, and GCC warns with -Wsign-compare about “comparison of integer expressions of different signedness”. The -1 turned into an enormous positive number. The infinite backwards loop of chapter 42 has the same root.

36.4 What kind of number is an address — name, size, order#

We have said several times that a pointer cannot be seen as “just a number”. What kind of number is it, then? Splitting the uses of number into three makes the answer sharp.

An address is not one of the three: it is all three, and none of them wholly.

• As a nominal number: the most basic use. &x is the name of the object x, and whether two addresses are the same may always be asked (which is why == and != are allowed even between different objects, appendix A). This is exactly what a locker number does.
• As an ordinal number: within one array, before and after mean something. &a[1] < &a[2] is true, and sorting, searching and bounds checks rest on that. But between different arrays the question cannot be asked — which is why ordering them is outside the contract (appendix A). What has an order is not addresses in general but addresses within one object.
• As a cardinal number: the difference of two addresses counts — not bytes but elements (chapter 39). &a[4] - &a[1] is 3, meaning “three elements apart”. And this subtraction, too, means something only within one array.

In short: an address may always be used as a nominal number; as an ordinal or a cardinal number only within one object. Half the strangeness of C’s pointer rules lives here — we learned numbers as things that are all three at once, while an address is whichever of the three the context allows.

Figure 36.3 — The three things that travel with one pointer value. The same address does not make the same pointer.

36.4.1 Why addresses are integers, of all things#

Naming an object could have been done otherwise — a name string, an index into a table, a handle; languages and operating systems have done all of these. C chose an integer for a simple reason: the machine was already doing it that way. As chapters 2–3 showed, a machine address is a number, adding to it gives the neighbouring slot, and CPUs have circuitry that computes “base + index × size” in one step. Choose an integer and arrays, strings and struct access all follow for free.

That choice became C’s power and its danger. The power is expressiveness — arrays arrive with no extra syntax (chapter 39), and memory can be handled in bulk (chapter 103). The danger is the illusion that the number may be handled like any other number.

36.4.2 The abstraction around pointers has thickened with time#

Pointers were not always as delicate as they are now. In early C a pointer was close to the machine address itself, and it was common practice to convert one to an integer, play with it and convert back. Machines were simple then — memory was one layer, instructions ran in the order written, and the compiler did not greatly rearrange what a person had written.

Since then the layers underneath have thickened.

• Memory split into levels (chapter 12) — registers, caches, DRAM, and above them virtual addresses and page tables. The number a program sees has already been translated.
• Execution began to overlap (chapter 13) — pipelines, out-of-order execution, branch prediction. “In the order written” is no longer true.
• The compiler became an editor (chapter 14) — it rewrites code wholesale so long as the observable behaviour is kept. One of the premises that rewriting rests on is “this pointer does not touch that object”.

The thicker those layers grew, the more the language had to ask of pointers. For a compiler to reorder on the premise that “distinct objects do not touch one another”, it needs a promise that the program will not break that premise. So pointers have drifted away from being numbers and been refined into located values with a contract — the alignment rules (chapter 38), provenance (chapter 38), and the rule against forming an address outside its array (chapter 39) are all clauses in that direction.

36.5 How to print an address#

One of the first things anyone does when debugging is look at where a pointer points. Even this ordinary act has a contract.

/* Addresses in a form people read — the contract of %p and the alternatives.
   * Addresses differ from run to run (ASLR), so this demonstration prints
     properties, not values: what is printed here must be the same every time. */
#include <inttypes.h>
#include <stdint.h>
#include <stdio.h>
#include <string.h>

int main(void)
{
    int n = 42;

    /* (1) %p takes a void* (and, from C23, a character-type pointer) only.
          Cast anything else — better to make it a habit. */
    puts("[the contract of %p]");
    printf("  a null pointer via %%p: %p   <- the form is implementation-defined\n",
           (void *)nullptr);
    puts("  Other addresses differ per run, so they are not printed here.");

    /* (2) print one address two ways and compare the strings */
    char a[64], b[64];
    snprintf(a, sizeof a, "%p", (void *)&n);
    snprintf(b, sizeof b, "%#" PRIxPTR, (uintptr_t)(void *)&n);
    printf("\n[do %%p and PRIxPTR produce the same text?]\n");
    printf("  on this implementation: %s\n", strcmp(a, b) == 0 ? "yes" : "no");
    printf("  same number of characters: %s (the value is not printed)\n",
           strlen(a) == strlen(b) ? "yes" : "no");

    /* (3) the guaranteed round trip is void* <-> uintptr_t */
    uintptr_t u = (uintptr_t)(void *)&n;
    printf("\n[the uintptr_t round trip]\n");
    printf("  is the pointer back equal to the original: %s\n",
           (void *)u == (void *)&n ? "yes — the standard promises it" : "no");

    /* (4) a fixed width keeps a log tidy (padded with zeroes) */
    char line[80];
    snprintf(line, sizeof line, "obj=0x%016" PRIxPTR, u);
    printf("\n[making one line of a log]\n");
    printf("  length of the line produced: %zu characters (constant, whatever the address)\n",
           strlen(line));

    /* (5) compare layout inside one array — subtracting across objects is outside the contract */
    int arr[3];
    printf("\n[comparing layout]\n");
    printf("  arr[0] to arr[1]: %td bytes (legal — the same array)\n",
           (char *)&arr[1] - (char *)&arr[0]);
    printf("  equal to sizeof(int): %s\n",
           (size_t)((char *)&arr[1] - (char *)&arr[0]) == sizeof(int) ? "yes" : "no");

    /* (6) a human-facing log wants names and ordinals, not addresses */
    puts("\n[names instead of addresses]");
    static const struct { const char *name; const void *at; } table[] = {
        { "n", nullptr }, { "arr", nullptr },
    };
    for (size_t i = 0; i < sizeof table / sizeof *table; i++)
        printf("  #%zu %-4s <- this name is what the log keeps\n", i, table[i].name);
    puts("  An address means something only within that run; the next run differs.");
    return 0;
}

[the contract of %p]
  a null pointer via %p: (nil)   <- the form is implementation-defined
  Other addresses differ per run, so they are not printed here.

[do %p and PRIxPTR produce the same text?]
  on this implementation: yes
  same number of characters: yes (the value is not printed)

[the uintptr_t round trip]
  is the pointer back equal to the original: yes — the standard promises it

[making one line of a log]
  length of the line produced: 22 characters (constant, whatever the address)

[comparing layout]
  arr[0] to arr[1]: 4 bytes (legal — the same array)
  equal to sizeof(int): yes

[names instead of addresses]
  #0 n    <- this name is what the log keeps
  #1 arr  <- this name is what the log keeps
  An address means something only within that run; the next run differs.

36.5.1 The exact contract of %p#

What the standard specifies (§7.23.6.1) is two lines.

Two practical rules follow at once.

First, cast anything else. Passing an int * straight in, as in printf("%p", &n), is outside the contract: variadic arguments carry no type check (chapter 67), and nothing guarantees that pointer types share a representation — the standard says only that void * and character pointers do, and states plainly that pointers to other types may not (§6.2.5p33).

printf("%p", (void *)p);      /* like this */
printf("%p", p);              /* not like this */

Second, do not lean on the output’s form. The demonstration printing a null pointer is the proof: this implementation writes (nil). The 0x prefix, the number of digits and the letter case all vary. So never write code that parses what %p produced.

36.5.2 When an address has to become a string — uintptr_t and PRIxPTR#

To put an address into a log buffer or to line columns up, %p is not enough. That is what uintptr_t from <stdint.h> and PRIxPTR from <inttypes.h> are for.

uintptr_t u = (uintptr_t)(void *)p;
snprintf(line, sizeof line, "obj=0x%016" PRIxPTR, u);

What the standard guarantees for uintptr_t is exactly this — any valid void * converted to it and back compares equal to the original (§7.22.1.4). The demonstration checks that round trip.

Two things to know. uintptr_t is optional, so an implementation may lack it (rare today), and the round trip is guaranteed for void * only — function pointers are outside that sentence (chapter 68).

36.5.3 But — does the address need printing at all?#

The last part of this section matters most. An address means something only within that run.

Today’s operating systems randomise the layout at every launch (ASLR), so the 0x7ffd… in yesterday’s log means nothing in today’s run. And once such a value gets out, it tells an attacker how memory is laid out — the first thing they look for.

36.6 The size of a pointer is not one number#

Here is why the answer above said “8 bytes on this machine” so carefully. The widespread belief runs: “a pointer is just an address, so within one machine they are all the same size.” On the x86-64 Linux we use today that is true, which is why the belief is so rarely contradicted. But the C standard never promised it, and real machines have broken it more than once.

What the standard actually promises is much narrower.

• void * and the character-type pointers (char *, signed char *, unsigned char *) have the same representation and alignment requirements as each other. Those four go together.
• Pointers to structures share a representation with one another; so do pointers to unions.
• Beyond that, nothing is promised. There is no rule that int * and double * must be the same size, and none that an object pointer and a function pointer must share a representation.

Why leave it so loose — because machines really were different.

Nor is this only in the past tense.

The concept of the pointer is now in place. The next chapter is this part’s first safety rule — how to handle “points nowhere.” The three nulls whose faces we learned in chapter 4 get their formal treatment, this time in syntax and practical rules.