The Preprocessor, Undefined Behavior, and Safe C

We’ve built up C from compilation to data structures. This final post covers the machinery that surrounds real C programs — the preprocessor and multi-file builds — and then the thing that makes C uniquely treacherous: undefined behavior. We end with the idioms that experienced C programmers use to stay safe, tying the series together into a practice.

The preprocessor

Recall from post 1 that before compilation, a preprocessor performs textual manipulation on your source, handling every line beginning with #. Its three main jobs:

• #include — literally pastes the contents of a header file into your source. #include <stdio.h> for standard headers, #include "myheader.h" for your own. This is how declarations (post 1) reach the files that need them.
• #define — defines macros, which are text substitutions. A simple constant macro replaces a name with a value; a function-like macro substitutes with arguments:

#define MAX_USERS 100
#define SQUARE(x) ((x) * (x))    // note the parentheses — see below

• Conditional compilation — #ifdef, #ifndef, #if, #endif include or exclude code based on conditions, used for platform-specific code and feature flags.

The crucial thing to understand: the preprocessor operates on text, not on C. It doesn’t understand types, scope, or expressions — it blindly substitutes. This makes macros powerful and dangerous. The classic macro bug shows why the parentheses above matter:

#define SQUARE_BAD(x) x * x
int r = SQUARE_BAD(2 + 3);   // expands to 2 + 3 * 2 + 3 = 11, NOT 25!

Without wrapping parentheses, text substitution ignores operator precedence and produces nonsense. This is why function-like macros parenthesize every argument and the whole body — and why modern C prefers const variables and real functions over macros wherever possible, using macros mainly for compile-time constants and conditional compilation. When you can use the type-checked language instead of blind text substitution, do.

Include guards and multi-file programs

Real C programs span many files, using the declaration/definition split from post 1: header files (.h) hold declarations (function prototypes, struct definitions, macros) shared across the program, and source files (.c) hold the definitions, each compiled independently to an object file and linked together.

A necessary companion is the include guard, which prevents a header from being pasted in twice (which would cause duplicate-definition errors when headers include other headers):

#ifndef MYHEADER_H     // if not already defined...
#define MYHEADER_H     // ...define it, and include the body once
// declarations here
#endif

The first time the header is included, MYHEADER_H isn’t defined, so the body is included and the guard defined; any later include sees the guard already defined and skips the body. Every header you write should have one (or the non-standard-but-ubiquitous #pragma once). This is the plumbing that makes multi-file C — the normal way real programs are structured — actually compile.

Undefined behavior: C’s sharpest edge

Now the most important concept for writing correct C. Undefined behavior (UB) is any operation the C standard declares has no defined meaning — the compiler is allowed to do literally anything: crash, produce wrong results, appear to work, or behave differently with optimizations on. UB is not “implementation-defined” (a documented choice) or “unspecified” (one of a few options); it’s a total absence of guarantees. The program is simply invalid, and anything is a conforming outcome.

You’ve met most of the common ones already in this series:

• Out-of-bounds array access (post 5) — reading/writing past an array or buffer.
• Dereferencing NULL or a dangling/uninitialized pointer (posts 4, 6) — use-after-free, wild pointers.
• Reading uninitialized variables (post 3) — the garbage-value trap.
• Signed integer overflow (post 2) — INT_MAX + 1 is UB (unlike unsigned overflow, which is defined to wrap).
• Double free (post 6), and invalid shifts (shifting by ≥ the type’s width).

What makes UB uniquely dangerous is the compiler’s freedom. Modern optimizers assume UB never happens and optimize on that assumption — so UB can cause bizarre, action-at-a-distance bugs where code far from the actual mistake behaves wrongly, and where adding a printf or changing optimization level makes the symptom move or vanish. A program with UB isn’t “a bit buggy”; it has no defined meaning, even if it happens to work today. This is why “it runs fine on my machine” is worthless evidence in C. The defense is to never invoke UB in the first place — which is exactly what the whole series’ discipline (stay in bounds, initialize, check pointers, match malloc/free, mind signedness) is for.

The safety idioms

C gives no safety for free, so experienced C programmers build it from habits. Pulling the series’ lessons into a checklist:

• Compile with warnings as your first defense — -Wall -Wextra, and treat warnings as errors (-Werror) in CI. The compiler catches a huge share of bugs if you let it.
• Initialize everything — variables and pointers (to NULL). Uninitialized reads are UB and among the most common C bugs.
• Check every pointer and every allocation — verify malloc/realloc didn’t return NULL; check for NULL before dereferencing.
• Match every malloc with one free; set freed pointers to NULL — the ownership discipline that defeats leaks, use-after-free, and double-free.
• Use bounded string/memory functions and always account for buffer sizes and the null terminator — never strcpy/gets on untrusted input.
• Run sanitizers and Valgrind routinely — AddressSanitizer, UndefinedBehaviorSanitizer (-fsanitize=undefined), and Valgrind catch the memory and UB bugs that testing misses.
• Prefer the type-checked language over the preprocessor — const and functions over macros where you can.

None of these is optional folklore; each closes a specific hole the language leaves open. Together they’re what “writing C well” means.

Where to go next, and the whole picture

You now have a foundation: compilation, types, functions and the stack, pointers, arrays and strings, the heap, structs and data structures, and the preprocessor and UB. From here, C opens onto the domains it dominates — systems programming (files, processes, syscalls), embedded and hardware, network programming, and reading the real C of Linux, SQLite, and language runtimes. The best next step is building: a real program (a small interpreter, a data-structure library, a command-line tool) is where the concepts fuse into fluency, exactly as with any language.

The through-line of the whole series is C’s bargain: it is a thin, compiled layer over the machine that gives you complete control over memory and near-total responsibility for correctness. Every feature — pointers, manual allocation, the unchecked array, undefined behavior — is that bargain in a different form: maximal power, minimal safety net. Mastering C is mastering the discipline that supplies the safety the language omits. Do that, and you don’t just learn a language — you understand what every higher-level language is built on top of, which is the real reason to learn C at all.

Key takeaways

• The preprocessor does textual substitution before compilation — #include (paste a header), #define (macros), and conditional compilation (#ifdef) — and because it manipulates text, not C, unparenthesized function-like macros produce precedence bugs, so prefer const and real functions where possible.
• Real programs are multi-file: headers (.h) hold shared declarations, sources (.c) hold definitions compiled separately and linked, and every header needs an include guard (#ifndef/#define/#endif or #pragma once) to avoid duplicate inclusion.
• Undefined behavior is any operation the standard gives no meaning — the compiler may do anything, and optimizers assume it never happens, causing bizarre action-at-a-distance bugs; a program with UB has no defined meaning even if it seems to work, so “runs fine on my machine” proves nothing.
• The common UB traps recur through the series: out-of-bounds access, NULL/dangling/uninitialized pointer dereference, reading uninitialized variables, signed integer overflow, and double free — the defense is to never invoke UB, which is what all the discipline is for.
• Safe C is a set of habits: compile with -Wall -Wextra -Werror, initialize everything, check every pointer and allocation, match malloc/free and null-out freed pointers, use bounded string functions, and run sanitizers/Valgrind — each closes a specific hole the language leaves open.

Further reading

• cppreference — Preprocessor
• cppreference — Undefined behavior