52 Undefined behaviour

52.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 the table above — 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 12 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”.

52.2 Why it exists

There are two reasons for leaving an outside-the-contract region. First, because machines differ — chapter 7′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 7 showed, the premise that “signed integers do not overflow” is what lets the compiler analyse and reorder loops (chapter 13). These clauses are the price of C remaining the language of speed for half a century.

52.3 The real face of “anything at all”

UB’s result is not only a collapse. The pattern seen in chapter 13 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.

52.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 seen in chapter 57 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.

52.5 Other curious pieces of UB

As of C23, annex J.2 lists 218 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 37 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 218 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 */
}

52.6 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 23), keep boundaries (chapter 38), check for null (chapter 36), change one variable only once in one statement (chapter 33), do not take shortcuts outside the contract (pointer casts, assumptions about representation) (chapters 11 and 37).

Tools — the nets equipped in chapter 17. 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 7 (“signed overflow is outside the contract”), governed by the discipline learned in chapter 51 (“errors are values”).

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

52.7 Closing Part IX

The part of precision is over — how to handle approximation (chapter 50), how to handle failure (chapter 51), and how to know the world outside the contract (chapter 52). The three 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 54), we face the layer of preprocessing and translation (chapter 57), we learn the terrain of the standard library (chapter 61), we treat proven head on (Part XII), and we close the book with the practices of modern C (chapter 98).

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.