54 Undefined behaviour

54.1 Three grey zones — UB, unspecified, implementation-defined#

Let us first separate three confusable words. Organised through the cases this book has met so far:

The first two are worlds where “there are several answers but there is an answer.” Only UB is a world where there is no answer at all.

The words again, nailed down. The three names in Table 54.1 — implementation-defined, unspecified, undefined behavior — are the standard’s own terms, written in the document itself. The phrase “grey area”, used in this chapter’s title and body, is, as chapter 13 said, a name this book adopted for convenience; it is not in the standard. When talking to anyone else, translate it into the exact word — not “that’s a grey area” but “that’s unspecified” or “that’s UB”.

54.2 Why it exists#

There are two reasons for leaving an outside-the-contract region. First, because machines differ — chapter 6′s shift of at least the width is the representative case. x86 and older ARM respond differently, and had the standard chosen one side the other machine would have to insert correction code every time. Instead of taking sides it said “do not write that code.” Second, to obtain premises for optimisation — as chapter 6 showed, the premise that “signed integers do not overflow” is what lets the compiler analyse and reorder loops (chapter 14). These clauses are the price of C remaining the language of speed for half a century.

54.3 The real face of “anything at all”#

UB’s result is not only a collapse. The pattern seen in chapter 14 is more frightening — the compiler reads UB as “a thing that cannot happen” and deletes code. A null check disappears entirely (if the pointer was already dereferenced, it infers “it cannot be null”), an overflow check disappears (since signed overflow is premised not to happen), a loop becomes infinite or vanishes altogether. So UB’s representative symptom is not “dying on the spot” but a bug that appears somewhere unrelated, disappears when the optimisation level changes, and is hard to reproduce.

54.4 Before the computation even begins — the UB of a file’s shape#

Undefined behaviour usually brings to mind an accident during execution, such as an overflow or a null dereference. Yet read the standard’s list (annex J.2) from the top and something surprising appears — the second entry is about the last character of a file.

That is, a file whose last line has no new-line at the end is outside the contract however perfect its grammar. This provision has been there since C89 and remains in C23 (ISO/IEC 9899:2024) — it is the second entry of annex J.2. C++, for reference, dropped the clause in 2011 (deciding that a missing new-line counts as one appended). It is a rare place where the two languages parted.

Why should such a thing be UB? Recall the translation phases touched on in chapter 8 — all eight are laid out in chapter 61 — and the answer appears. The preprocessor works by lines, and one directive is complete only when a new-line ends it. If the file ends with no new-line, the last line is left unfinished, and what happens next differs by implementation. The third row’s “partial token” is the same circumstance — if the file ends with an unclosed string literal or a comment with no */, the preprocessor has no ground on which to judge whether to keep reading into the next file.

Today’s compilers mostly append a new-line quietly (older GCC gave warning: no newline at end of file). So the place this clause makes trouble in practice is not the compiler but the other tools that handle the file.

54.5 Other curious pieces of UB#

As of C23, annex J.2 lists 221 kinds of undefined behaviour. Most are things one will never meet in a lifetime, but among them are several entries that make one ask “even this?”. We pick out those that happen in the world of characters and names, unrelated to computation at run time.

The first three are the other faces of the “file shape” entry seen in the previous section. A file ending with an unclosed comment or string falls under the same clause — it looks as though it would fail to compile anyway, but in the standard’s eyes it is a place where not even a diagnosis is required.

The two rows in the middle are especially practical. Writing #include "utils\str.h" on Windows is undefined behaviour as far as the standard goes — in reality MSVC handles it for you, but it becomes a problem the moment you port. What the standard guarantees is / alone, and happily the Windows compilers accept / too. Hence the advice always to use / in header paths.

The short *p = &a[15]; row surprises people too. Without reading or writing anything, merely making the pointer is outside the contract (only up to one past the array’s end is permitted). It is why “I only compute the address and never use it” does not hold, and the ground on which chapter 38 drew a boundary round pointer arithmetic.

The last row shows this list’s character well. One wide-character conversion function carries the condition that “the locale must be the same as when wctrans was called”, and breaking it is UB. Most of the 221 are of this grain — very narrow, very specific, and never met in a lifetime.

void copy(int *dst, const int *src, size_t n) {
    memcpy(dst, src, n * sizeof *dst);   /* UB if n == 0 and both are null */
}

54.6 UB you create on purpose — unreachable#

Everything so far has been undefined behaviour to avoid. C23 brought in one word that runs the other way — a device for promising the compiler that “control never comes here”.¹

#include <stddef.h>

const char *name_of(enum color c)
{
    switch (c) {
    case RED:   return "red";
    case GREEN: return "green";
    case BLUE:  return "blue";
    }
    unreachable();          /* those three are all of them --- arriving is my bug */
}

The standard’s wording is exactly that shape — it “indicates that the particular flow control that leads to the invocation will never be taken”, and program execution “shall not reach such an invocation”. Reaching it is undefined behaviour.

★ So this is a contract, not a check (chapter 53). Set beside assert, the character is plain.

What you gain is size and speed. In the function above the compiler learns that there is no path out of the switch, and drops the handling for a return-less path. What you lose is the safety net — add a colour later and forget to update the switch, and a place that used to return something odd becomes a place that can do anything at all.

The working rule is therefore short. Write it only when you can truly prove it. Where the judgement is not firm, return an error or call abort() instead — both stay inside the contract.

54.7 How to avoid it — discipline, tools, and components#

Defence in practice is three layers.

Discipline — the rules this book has passed through are the list: initialise before use (chapter 24), keep boundaries (chapter 39), check for null (chapter 37), change one variable only once in one statement (chapter 34), do not take shortcuts outside the contract (pointer casts, assumptions about representation) (chapters 12 and 38).

Tools — the nets equipped in chapter 18. Compiler warnings catch at compile time; UBSan and ASan catch at run time. The checked arithmetic brought in by C23 is a tool of this layer too — functions that report overflow as a value instead of making it UB:

#include <stdckdint.h>
#include <stdio.h>

/* C23's checked arithmetic: on overflow it returns true, and the result holds the wrapped value. */
int main(void)
{
    int a = 2000000000;
    int b = 2000000000;
    int sum = 0;

    if (ckd_add(&sum, a, b)) {
        printf("%d + %d overflows int (we stayed inside the contract)\n", a, b);
    } else {
        printf("sum: %d\n", sum);
    }

    int small = 0;
    if (ckd_add(&small, 20, 22)) {
        printf("overflow\n");
    } else {
        printf("20 + 22 = %d\n", small);
    }
    return 0;
}

2000000000 + 2000000000 overflows int (we stayed inside the contract)
20 + 22 = 42

ckd_add returns “did it overflow?” as its return value — the standard’s answer to the trap learned in chapter 6 (“signed overflow is outside the contract”), governed by the discipline learned in chapter 53 (“errors are values”).

Components — using an API in which violating the contract is difficult to begin with (chapter 44′s proven is that layer). Chapter 18′s metaphor — tools are nets, good components are footholds — is completed here.

54.8 Closing Part IX#

The part of precision is over — how to read an operator as a contract (chapter 50), how to put bits to work (chapter 51), how to handle approximation (chapter 52), how to handle failure (chapter 53), and how to know the world outside the contract (chapter 54). The five chapters share one theme: C is a language that entrusts much to the programmer, and the person who knows what has been entrusted writes safe code.

The last parts remain. Every program so far has been a single file — now it grows into several files (chapter 56), we face the layer of preprocessing and translation (chapter 61), we learn the terrain of the standard library (chapter 66), we treat proven head on (Part XII), and we close the book with the practices of modern C (chapter 105).

The next part is the story of composing a program. Its first chapter is the place we have used only as a six-line convention until now — main itself. We see its three forms, and where the value it returns goes.