What Undefined Behavior Really Means

The word you have been mishearing

In the last guide you met the C abstract machine — the idealized computer the C standard describes, the one your source code is really written for. You saw that the as-if rule lets a real compiler do anything it likes to your code as long as the visible behavior matches what that abstract machine would produce. Undefined behavior, almost always shortened to UB, is what happens at the exact spot where that contract tears. It is a construct or situation for which the standard places no requirements at all — it simply walks away and says nothing about what the program means from that point on.

Here is the sentence almost everyone gets wrong, so read it slowly: UB does not mean 'the result is unpredictable' or 'it depends on the platform'. It means the standard has stopped describing your program entirely. A program that executes UB has, formally, no defined behavior — not a wrong answer, not a platform-specific answer, but no required answer at all. The compiler is under no obligation to make it crash, to make it print garbage, or to do anything in particular. The most useful mental model is a promise: every place the standard says 'this is undefined' is a place where the language standard is really saying *'you, the programmer, promise this never happens — and we will build everything on top of that promise.'*

Three siblings that are easy to confuse

UB has two milder relatives, and keeping the three apart is the cleanest way to feel where the real cliff is. They form a ladder of how much the standard promises. At the safe end sits implementation-defined behavior: the standard insists the implementation pick one consistent answer and write it down in its documentation. The width of an int, for example, or whether a plain `char` is signed — these vary between platforms, but each compiler must choose and tell you. Your program stays meaningful; you just have to read the manual.

One rung less safe is unspecified behavior: the standard offers a small menu of allowed outcomes but does not require the implementation to document which it picks, and it may even differ from one occurrence to the next. The classic example is the order in which a function's arguments are evaluated: in `f(g(), h())` the standard guarantees both g() and h() run before f(), but says nothing about which runs first. Both unspecified and implementation-defined behavior keep your program meaningful — the result is one of a known, bounded set of possibilities. The danger is mistaking the third sibling for these two.

Undefined behavior is categorically different. There is no menu, no documentation, no bounded set — there is nothing. With the first two, the worst case is a portability bug: your program behaves differently on a different compiler, but it still behaves. With UB, there is no 'behaves' to speak of. So the honest one-line rule is: implementation-defined and unspecified are about which of several valid answers you get; undefined is about whether your program means anything at all. Reach for the manual on the first two; never knowingly trigger the third.

implementation-defined : standard says "pick one, and document it"  -> int width, char signedness
unspecified            : standard says "pick from this set, no docs"  -> argument eval order
undefined (UB)         : standard says NOTHING                         -> null deref, signed overflow

        safer  <----------------------------------------------------------->  catastrophic
   (a portability bug)                                          (your program means nothing)

Why the optimizer is allowed to delete your code

This is the part that turns UB from a pedantic footnote into a genuine hazard, and it follows from one airtight piece of logic. The optimizer's whole job is to make valid assumptions and exploit them. Its most powerful assumption is this: *the program never executes undefined behavior.* It is entitled to assume this because the standard let it — UB is, by definition, the programmer's promise. So whenever the compiler can prove that a certain path would lead to UB, it is free to conclude that path never runs, and to reshape your code on that basis. Watch it happen on a tiny example, where a programmer writes a null-check after dereferencing — a common ordering mistake:

int value = *p;        // (1) dereference p
if (p == NULL) {       // (2) ...then check if p was NULL
    return -1;
}
return value;

// The compiler reasons:
//   line (1) dereferences p. If p were NULL, that is UB.
//   I am allowed to assume UB never happens.
//   Therefore p is NOT NULL at line (1).
//   Therefore the check at line (2) is always false.
//   => delete the entire if-block.

Read that reasoning again — every step is correct. The dereference on line (1) is UB if p is null, so the compiler assumes p is non-null right there. But if p is non-null at line (1), the check `p == NULL` on line (2) must be false, so the safety net the programmer carefully added gets deleted as dead code. The result is a program that, at `-O2`, will happily charge past a null pointer it 'checked' for — while the very same source compiled at `-O0` keeps the check and seems fine. The bug did not appear; it was always there. The optimizer merely cashed in the promise you didn't know you'd made.

This is why the slogan 'UB is just platform-dependent behavior' is so dangerous. Platform-dependent behavior is stable: the same compiler gives the same answer every time. UB is worse than random — it changes with optimization level, with compiler version, with code a hundred lines away, and it can make working code stop working with no source change at all. A bug that vanishes at `-O0` and corrupts memory at `-O2` is the signature of UB, and you should learn to recognize it like a smell.

Time travel: when the corruption arrives before the cause

There is one more consequence that genuinely unsettles people the first time, and it has earned the nickname UB time travel. Because the compiler is allowed to assume UB never happens, and because it reorders instructions freely under the as-if rule, the effects of a piece of UB can appear to happen before the line that triggers it. A `printf` that the programmer placed safely above the offending line may never run, because the compiler reasoned backward from the UB and deleted everything on a path it 'proved' could not be taken.

Let the picture be concrete. Imagine code that prints 'starting' and then, ten lines later, divides by a variable that turns out to be zero — division by zero being UB for integers. You might expect 'starting' to print and then the crash. But the compiler is allowed to fold and reorder the whole region, and may emit a binary where the program faults before 'starting' ever reaches the screen, or where 'starting' is gone entirely. This is why you cannot reliably use a trail of print statements to bracket UB: the UB poisons the whole region of code the optimizer considered together, not just the single guilty line. Causes and effects stop lining up in source order.

The lesson is not to be paranoid about every line but to update your model of what a C program is. Your source is not a script the machine reads top to bottom; it is a description that the compiler is free to transform in any way the as-if rule permits — provided you never trigger UB. The moment you do, the as-if rule's guarantee evaporates, and there is no longer any relationship at all between the order of your source and the order of what runs. UB is the one thing that can make your code lie to you about its own sequence.

The usual suspects, and how to catch them

Most everyday UB comes from a short list of repeat offenders, and naming them now means you will recognize each when the next guide examines it up close. The big ones are: dereferencing a null or dangling pointer; reading or writing outside an array, which is the seed of every buffer overflow; signed integer overflow (note that unsigned overflow is defined to wrap, but signed overflow is UB); reading an uninitialized variable; using memory after free(); and a few subtler ones like type-punning that breaks strict aliasing or shifting an integer by more than its width.

Notice what these share: each is a place where the standard handed the compiler a promise to optimize against. That is also the good news. Because UB is precisely defined, tools can be built to catch it. The single most valuable habit you can form now is to compile with a sanitizer turned on while you develop: `gcc -fsanitize=undefined,address -g main.c` arms the undefined-behavior sanitizer and the address sanitizer, which insert the very runtime checks the optimizer was allowed to omit. Instead of silently miscompiling, your program now stops at the exact line with a clear diagnostic — turning an invisible promise into a loud, locatable error.

Holding the idea straight

Step back and the shape is simple, even if the consequences are sharp. The C standard defines a careful contract between you and the compiler. Most of that contract is firm guarantees. A few corners are deliberately left undefined, and at each of those corners the compiler is allowed to assume — and to build optimizations on the assumption — that your program never goes there. Honor the contract and you get a fast, predictable program. Violate it, even once, even on a line you thought was harmless, and the compiler's reasoning is free to ripple outward and reshape code far from the violation.

So carry these three corrections out of this guide, because they are the exact three that working programmers most often get wrong. UB is not 'undefined output' — it is the absence of any defined meaning. UB is not 'platform-dependent' — it is worse, because it is unstable under the optimizer and can change with a flag. And UB is not 'something the compiler does to you' — it is something you promised would never happen, which the compiler simply took at its word. The next guide, The Common Traps, takes the suspects we just named and walks through exactly how each one fires and how to defuse it.