38 The rules of pointers — alignment and provenance

38.1 Alignment and casts — the privilege of char*#

Pointer casts (looking through a changed type) are grammatically free but narrow by contract. Reduced to a practical sentence — a cast to a type demanding stricter alignment is dangerous whenever the address does not satisfy that alignment. Converting an unaligned char* into an int* (alignment 4) and following it is the typical violation; converting back a pointer that originally came from a properly aligned int object is fully defined. The opposite direction is safe — and here lies a privilege C intended: a pointer to a character type (char*, signed char* and unsigned char*) may look at any object byte by byte. With alignment 1 it can point anywhere, and the standard explicitly permits that “the representation of any object may be read through the eye of bytes” (chapter 14′s strict aliasing has this exception carved into it too). The official channel for the perspective of chapter 3, “inside a slot it is only bits”, is unsigned char*.

The alignment requirement of each type can be asked with alignof (a C23 keyword):

#include <stdio.h>

int main(void)
{
    printf("alignof(char)   = %zu\n", alignof(char));
    printf("alignof(int)    = %zu\n", alignof(int));
    printf("alignof(double) = %zu\n", alignof(double));
    return 0;
}

alignof(char)   = 1
alignof(int)    = 4
alignof(double) = 8

38.1.1 The two privileges side by side#

Here we tidy up the two passages announced in chapter 36. They do different work.

This is why memcpy takes void * in its prototype and copies bytes inside — it forgets the type on the way in and looks at bytes on the way through. That the standard requires void * and the character-type pointers to share a representation is for exactly this combination (chapter 36′s word-addressed machines).

38.2 Provenance — the same number, a different origin#

Here chapter 15′s foreshadowing turns into practical instinct. In the naive picture a pointer is only a number, so if the number is right it should be followable however it was made — but the contract of modern C is not like that. A pointer has an origin (provenance): an invisible tag saying which object it derived from. Reduced to three practical rules.

• Pointer arithmetic stays inside the object it was born in. Taking a pointer that started from one object’s address and pushing it (chapter 39) onto another

object — even if the number really does coincide with that object — is outside the contract.

• One past the end is permitted. Pointing at the slot “after” the end of an array (one-past-the-end) is legal (as long as you do not follow it). It is so useful in a loop’s ending condition that the standard carved out this place specially (in action in chapter 39).
• To treat it as a number, use the official channel. Converting a pointer to an integer to store or compute with it (such as chapter 4′s tagged pointers) has a road provided by the contract: going through the dedicated type uintptr_t.

38.2.1 A word that is not in the standard yet#

One thing must be said honestly here. Provenance is not a term of the C23 standard text. Search C23 from cover to cover and there is no clause defining that word. This book still spends a section on it for three reasons.

1. Compilers already optimise on this concept. That it is absent from the standard does not mean it may be kept or ignored at will.
2. The committee has finished writing it down, in a separate technical specification (ISO/IEC TS 6010, 2025). Only the folding into the main text remains.
3. What that specification does is not to pile on new rules but to fill the gaps between rules that already existed and make them fit together.

The third is the heart of this section. Even when the concept enters the standard, there is no new syntax to learn. The rules you must keep stay as they are — but for the first time the standard will explain, in one word, why.

38.2.2 Where was the gap — two neighbouring variables#

Look at just one place where the explanation stalls without this concept. Two variables laid side by side at file scope.

int y = 2, x = 1;
int *p = &x + 1;      /* the slot "one past" x — making it is legal */
int *q = &y;
if (p == q)           /* this can be true */
    *p = 11;          /* but what about this line? */

The question splits in two. Can p == q be true? It can. If the two variables really are placed next to each other the addresses coincide, and which way the comparison then goes is not fixed by the standard (unspecified). Then, inside that true branch, may y be modified through *p? No. p was born from x, and the one-past-the-end slot is legal to point at, not to follow.

This is where the naive picture collapses. “Two pointers that answered equal cannot be used interchangeably” is a self-contradiction in the pointer = number picture. And it is the real compilers that stand on the contradictory side — with optimisation on, GCC and Clang alike move and delete code on the premise that “p and q came from different objects, so they cannot overlap.” The code above therefore leaves y at 11 or at 2 depending on the compiler and the optimisation level. It matters, too, that this is separate from chapter 14′s strict aliasing — -fno-strict-aliasing does not make this premise go away.

The standard’s text was silent about the situation. As a result three parties have been talking past each other for twenty years. The text reads as “a pointer is a value”, the compiler optimises as “different origin, different thing”, and the programmer says “it ran on my machine.” With no referee, one cannot even decide whether the compiler produced a bug or the program broke the contract.

38.2.3 Where the word was born — DR260#

The word first appears in an official document in 2004, in the committee’s response to Defect Report 260. The gist reduces to two sentences.

“ An implementation may track the origins of a bit pattern. Pointers with different origins may be treated as distinct even when they are bitwise identical. ”

Permission was granted. But that permission never reached the standard’s text. There was no definition, and no boundary of what was allowed. In that state the compilers went ahead and built provenance-based alias analysis on the response.

What happens when an undefined concept becomes the ground of optimisation — that is the lesson of this story. Nobody can settle which idiom is legal. Half of the old low-level code sinks into a grey zone.

38.2.4 Writing it down — from a questionnaire to a technical specification#

It is worth noting that the work began in an unusual way. What came first was not drafting clauses but asking. In 2013 researchers at Cambridge circulated a survey of forty-two questions on pointers and object representation, gathering what working C programmers and implementers actually take to be legal, and the analysis went to the committee as documents.¹ Only then were the open issues distilled into twenty questions (Q1–Q20) and put to the committee as “ought this to be legal?”² Measuring what reality does before changing the standard.

A model was built on top of that. Its name is PNVI-ae-udi; the name is not worth memorising, and in practice it is three lines.

1. Every object (allocation) carries one invisible tag of origin. A pointer value is the pair «origin + address».
2. Casting a pointer to an integer exposes that object’s address (address exposed).
3. Casting an integer back to a pointer looks among the objects that have been exposed for one holding that address and revives its origin. If none was ever exposed, there is no origin to revive — such a pointer cannot be followed.

In a single line: only an object whose address was once handed out as an integer can be recovered from that integer. Why a uintptr_t round trip is the official channel, and why an address assembled out of bytes is not, both fall out of that one line — the two rules are not separate decrees but consequences of one model. That is what “tidying up” means here.

The result of the work is ISO/IEC TS 6010 (2025), “a provenance-aware memory object model for C”.³ It came out not as the standard’s text but as a separate Technical Specification, and it defines itself in those terms — not a complete specification of the language, but a document that constrains and clarifies the memory object model implicit in ISO/IEC 9899:2018. A conforming implementation must behave “as if these indicated differences to ISO/IEC 9899:2018 had been integrated into ISO/IEC 9899”.

It also marks its own boundary: this specification does not address subobject provenance. How far a pointer to a structure member may walk is still an open question.

The numbers and names are not for memorising. One thing is worth keeping: pointer provenance is not anyone’s taste but a concept hardened into a document through the standardisation process, and a candidate for the next revision’s text.

38.2.5 What changes if it lands#

To answer the most important part first — nothing happens to most code. No new keyword, no new syntax, no reason to rebuild. What changes is the number of greys. The idioms now sunk in the grey zone separate into black and white.

What to read in the table is not the individual verdicts but the fact that verdicts became possible. Today those cells could only say “probably”. The other changes are these.

• The compiler gains a ground. Today’s provenance-based optimisation leans on a single twenty-year-old defect response. With the model in the text, which rearrangement is legal can be decided mechanically — meaning there is finally a referee between a compiler’s bug and a program’s violation.
• Tools become precise. A sanitiser (chapter 18) catches “a bad address” today but is poor at “an address with the wrong origin”. Once the rules are written down, a diagnostic can say “the origin was lost here”, and formal verification tools gain a basis for proving C programs correct.
• Teaching and documentation change. Explanations that ended at “that is UB (undefined behaviour)” become “that pointer was not born from this object”. Which is exactly the shape of the explanation this book is giving now.
• This is not C’s problem alone. Rust settled the same problem first at library level — APIs such as with_addr, which swaps only the address, expose_provenance, which makes exposure explicit, and with_exposed_provenance, which takes it back; they were stabilized in release 1.84 in January 2025.⁴ The same discussion runs through LLVM’s intermediate representation. That several languages converge on the same conclusion says this is not C’s sophistry but the nature of the machinery called a compiler.

38.2.6 Machines that carry the origin in hardware#

None of this is confined to paper. Machines already exist in which the origin rides on the pointer and the hardware enforces it.

To sum up, there are two referees. On x86-64 the price of breaking provenance is collected by the compiler (so it is quiet and late); on a capability machine it is collected by the hardware, on the spot (so it is loud and immediate). Either way it is collected.

We have the rules of pointers too. Now we take these tools to contiguous memory — the array. The credit of line[100], carried since chapter 26, is settled in the next chapter.