C Preprocessor Directives: How Source Code Is Prepared Before Compilation

The Build Pipeline: Where the Preprocessor Fits

   main.c     │     ▼ ┌──────────────────┐ │  PREPROCESSOR    │   #include spliced in, #define substituted, │  (text handling) │   conditionals resolved, comments removed └──────────────────┘     │     ▼   main.i  ← the "translation unit" — pure C, no directives left     │     ▼ ┌──────────────────┐ │    COMPILER      │   parses and type-checks real C, emits assembly └──────────────────┘     │     ▼   main.s     │     ▼ ┌──────────────────┐ │   ASSEMBLER      │ └──────────────────┘     │     ▼   main.o     │     ▼ ┌──────────────────┐ │     LINKER       │   combines .o files and libraries └──────────────────┘     │     ▼   a.out / a.exe

Every line beginning with # is a directive, and it is handled entirely in that first stage. By the time the compiler runs, there are no directives left — the output is ordinary C.

You can watch this happen. The command-line option -E runs only the preprocessor:

gcc -E main.c -o main.i
# preprocess only, write the translation unitgcc -E -P main.c
# omit the
#line markers, cleaner to readgcc -E -dM main.c
# dump all predefined macros instead of the codegcc -E -dD main.c
# keep
#define directives in the output too

When you're confused about what the preprocessor did, do this. It's the single most effective debugging technique for macro problems — main.i shows you exactly what the compiler is being handed, and macro bugs become obvious when you read it.

Two language-level facts that follow from this pipeline:

• The preprocessor is line-oriented. A directive runs from # to the end of its line. To continue one across multiple lines, end each line with a backslash \.
• main.i is a "translation unit." It's what the compiler actually compiles — a single, self-contained stream of C with everything included and expanded.

(Suggested image: the pipeline drawn as five stages with the preprocessor stage highlighted, and a side panel showing main.c vs main.i side by side)

#include: Textual Insertion, Not Import

#include does the simplest thing imaginable: it opens the file and pastes its entire contents into your source at that point.

#include <stdio.h> /* angle brackets: "system" headers */
#include "myheader.h" /* quotes: "your" headers */

The difference between the two forms is the search order:

So quotes are for your own project headers, and angle brackets are for library and system headers. Getting them the wrong way round usually still works — until you have a local file that shadows a system header, which is a genuinely confusing bug when it happens.

What gets pasted is the whole file, verbatim — including its own #include directives, which are then processed recursively, and its own #defines, which then apply to everything after the include point. An include is not scoped, not namespaced, and not ordered by dependency. It's textual.

The double-inclusion problem

Because #include is textual, including the same header twice puts its contents in your source twice:

#include "point.h"
#include "point.h" /* spliced in a second time! */

If point.h contains a definition — a typedef, a struct, an enum — the second copy is a duplicate definition:

error: redefinition of 'Point'

This is common without anyone writing it twice, because one header includes another that's already included elsewhere.

Verified demonstration. Preprocessing a file that includes an unguarded header twice produces two copies of the definition:

SCENARIO 1: point.h with NO include guard--- preprocessed output(#include spliced in) ---typedef struct {
    int x, y;
}
Point;
typedef struct {
    int x, y;
}
Point;
int main(void) {
    Point p;
    return 0;
}
typedef-struct definitions in the translation unit: 2-> redefinition of Point: YES(compile error)

The fix: include guards

The standard solution is a wrap of conditional compilation — and note that it works purely through the mechanisms you've just learned: #ifndef, #define, and textual substitution.

/* point.h */
#ifndef POINT_H /* if POINT_H is NOT defined... */
#define POINT_H /* ...define it, and process the contents */
typedef struct {
    int x, y;
}
Point;
#endif /* POINT_H */ /* end of the guarded region */

Why it works, step by step:

1. First inclusion:POINT_H isn't defined, so the body is processed — and #define POINT_H is executed.
2. Second inclusion:POINT_His now defined, so #ifndef is false and the body is skipped entirely.
3. The body's contents land in your translation unit exactly once, no matter how many times or by which routes the header is included.

Verified — the same double-include, now guarded:

SCENARIO 2: point.h WITH
#ifndef include guard--- preprocessed output(#include spliced in) ---typedef struct {
    int x, y;
}
Point;
int main(void) {
    Point p;
    return 0;
}
typedef-struct definitions in the translation unit: 1-> redefinition of Point: no(guard worked)

Conventions worth adopting:

• The guard name should be unique across the whole project — typically the filename uppercased with underscores (POINT_H, NETWORK_SOCKET_H). A collision with another header's guard silently makes yours disappear, which is a nasty bug to track down.
• Never use a leading underscore for guard names — those are reserved for the implementation.
• Comment the #endif with the guard name (#endif /* POINT_H */) so long headers stay readable.
• Guard every header, no exceptions, even ones you think will only be included once.

#pragma once

Most compilers (GCC, Clang, MSVC) support this single-line alternative:

#pragma oncetypedef struct {
    int x, y;
}
Point;

Advantages: one line, no name to invent, no collision risk, and typically faster (the compiler remembers the file rather than re-reading it to check guards).

Disadvantages:#pragma once is not standard C — it's a widely supported extension. And it identifies files by path, so the same file reachable through two different paths (a symlink, a relative vs absolute include, a case-insensitive filesystem) can still be included twice.

Practical recommendation: include guards are portable and always correct; #pragma once is convenient. Many projects use both — #pragma once for speed plus a conventional guard for portability. Either is far better than nothing.

(Suggested image: the second-inclusion path shown with the guard blocking it — a "skipped" panel where the body would have been)

#define: Macros Are Text Substitution

There are two kinds of macro, and the difference between them is a pair of parentheses in the definition.

Object-like macros — simple names for values

#define PI 3.141592653589793
#define MAX_ITEMS 100
#define APP_NAME "PreprocDemo"
#define TAB '\t'
#define NEWLINE "\n"

Wherever the name appears in later code, it's replaced. Verified translation unit — starting from this source:

#include "lib.h"
#include "lib.h"
int main(void) {
    int buffer[MAX_ITEMS];
    printf("%s version %d\n", APP_NAME, VERSION);
    return 0;
}

with lib.h containing VERSION, APP_NAME, and MAX_ITEMS behind an include guard, the preprocessor produces:

int main(void) {
    int buffer[100];
    printf("%s version %d\n", "PreprocDemo", 3);
    return 0;
}

Checks on the output: #include lines remaining: 0 · macro names left unexpanded: 0 · lib.h spliced in exactly 1 time (the guard working). Notice that the second #include contributed nothing at all — and that buffer[100] is now a plain array declaration the compiler understands.

The rules that follow from "it's text":

• A macro is not a variable. It has no address, no type, and no scope. It exists only as a name the preprocessor replaces.
• A macro name is not substituted inside string literals. With #define VERSION 3, the literal "the VERSION here" stays exactly as written — the preprocessor doesn't scan inside strings.
• A macro's effect starts at its definition and runs to the end of the file — including into code below, past function boundaries, and inside any file that includes it afterward. There's no block scoping.
• #define inside a function body still has file scope from that point on. It looks local and isn't.

Function-like macros — text with parameters

Put (immediately after the name and it becomes parameterized:

#define SQUARE(x)((x)*(x))
#define MAX(a,b)((a)>(b)?(a):(b))
#define MIN(a,b)((a)<(b)?(a):(b))
#define CLAMP(v,lo,hi)((v) <(lo) ?(lo) :((v) >(hi) ?(hi) :(v)))

The critical detail: the ( must be adjacent to the name. A space turns it into something completely different —

#define SQUARE(x) /* ⚠ this is an OBJECT-like macro named SQUARE */ /*   whose body is the token sequence  (x)      */

Now SQUARE(9) expands to (x)(9) — a bewildering error. The same space-insensitive confusion does not exist anywhere else in the preprocessor, and it catches people once.

The parenthesis rule — and why it's not optional

#define SQUARE(x) x*x is the classic mistake. Verified expansion and evaluation:

SQUARE(x) = x*x SQUARE(1+2) -> 1+2*1+2 C evaluates: 1 + 2*1 + 2 = 5 <-- WRONG(operator precedence)
SQUARE(x) =((x)*(x)) SQUARE(1+2) ->((1+2)*(1+2)) C evaluates:(1+2)*(1+2) = 9 <-- CORRECT

The substitution is purely textual: x was replaced by 1+2without parentheses, producing x*x → 1+2*1+2. Normal C precedence then evaluates 2*1 first, giving 1 + 2 + 2 = 5 instead of the intended 9.

A second, larger failure of the same kind:

SQUARE(a+b) where a=3, b=4(expected 49) x*x -> a+b*a+b = 19 <-- wrong((x)*(x)) ->((a+b)*(a+b)) = 49 <-- correct

That's a silently wrong answer with no warning, in code that reads correctly. The rule has two halves, and both are required:

Wrap every parameter in parentheses. Wrap the entire macro body in parentheses too.

The body needs its own outer parentheses so the macro composes safely inside a larger expression:

#define DOUBLE(x)(x)+(x) /* ✗ body not enclosed */2 * DOUBLE(3) /* → 2 * (3)+(3) = 9, not 12 */
#define DOUBLE(x)((x)+(x)) /* ✓ */2 * DOUBLE(3) /* → 2 * ((3)+(3)) = 12 */

Multiple evaluation: arguments can run twice

This is the subtler hazard, and it can't be fixed with parentheses:

#define MAX(a,b)((a)>(b)?(a):(b))int m = MAX(i++, j++);

The argument a appears twice in the body ((a)>(b) and the ? (a)), and b appears twice too. So the arguments are evaluated multiple times.

Verified simulation of MAX(i++, j++) with i = 1, j = 2:

i started at 1, j started at 2;
call MAX(i++, j++) result m = 3 i is now 2(incremented 1x) j is now 4(incremented 2x) <-- TWICE, not once!total side effects: 3 increments for ONE apparent "argument each"

j was incremented twice — once in the comparison, once in the chosen branch. The programmer wrote two ++ and got three increments. That's undefined behavior territory, and it's completely invisible at the call site.

The rule that prevents it: never pass an argument with a side effect (increment, decrement, assignment, function call) to a macro that uses it more than once. Since you can't know that from the call site, the practical guidance is stronger:

Never pass anything with a side effect to a macro. Use a function instead.

Macros vs functions

The honest comparison:

Use a function unless you specifically need what only a macro provides — a type parameter, sizeof on the caller's actual array, no call overhead in a hot path, or participation in conditional compilation. Modern compilers inline small functions aggressively, so "performance" is rarely a real justification anymore.

Except for the array-length idiom, where a macro is genuinely the only option:

#define ARRAY_LEN(a)(sizeof(a) / sizeof((a)[0]))
int data[50];
printf("%zu\n", ARRAY_LEN(data));
/* 50 */

This only works on a real array in the same scope — pass it a pointer and you get the pointer's size divided by the element size, which is why it's so easy to get wrong. (It's the "arrays decay to pointers" rule, showing up inside a macro.)

(Suggested image: the SQUARE comparison — the bad expansion 1+2*1+2 and the good ((1+2)*(1+2)) side by side with their results 5 and 9 marked correct/incorrect)

Multi-Statement Macros and the do { } while (0) Idiom

A macro that expands to several statements has a specific problem. Naively:

#define SWAP(a, b) {
    int t = a;
    a = b;
    b = t;
}
/* ⚠ */

Used inside an if without braces:

if (x > y) SWAP(x, y);
else puts("already ordered");

After expansion:

if (x > y) {
    int t = x;
    x = y;
    y = t;
}
;
/* ← this semicolon! */else puts("already ordered");
/* ← orphaned else: compile error */

The user's ; after the macro becomes a null statement, which terminates the if — leaving the else with no if. It compiles fine in the bare form and breaks the moment it's used in an if/else. That's the worst kind of bug: it depends on where the macro is used.

The standard fix wraps the body in a loop that runs exactly once:

#define SWAP(a, b) do {
    int t = a;
    a = b;
    b = t;
} while (0)

Now the expansion is:

if (x > y) do {
    int t = x;
    x = y;
    y = t;
} while (0);
/* one complete statement */else puts("already ordered");
/* else still attached ✓ */

The do { } while (0) consumes the caller's semicolon correctly, behaves as a single statement in every context, and requires a trailing ; at the call site just like any other statement — so it looks like a function call:

SWAP(a, b);

Two cautions: the temporary t could shadow an outer t — the block scope inside do { } protects the caller's variable, but if the macro's arguments are named t themselves you'd have a conflict, so distinctive internal names are worth using. And do { } while (0) contains break/continue semantics — the block is a real loop, so a break inside would exit it.

A useful companion idiom for "does nothing when disabled," so a macro can be switched off without leaving syntax errors:

#ifdef DEBUG
#define DBG(...) do {
    fprintf(stderr, __VA_ARGS__);
} while (0)
#else
#define DBG(...)((void)0) /* a valid, do-nothing statement */
#endif

(Suggested image: the SWAP macro used in an if/else — first the broken expansion with the orphaned else, then the do-while(0) version working)

The # and ## Operators

These two operators exist only inside macro bodies.

# — stringize

Turns the macro argument into a string literal:

#define STR(x)
#x
#define XSTR(x) STR(x) /* two-step, so a macro arg expands first */
STR(hello) /* → "hello"                        */STR(1 + 2) /* → "1 + 2"      (not 3 — it's text!) */

Why the two-step XSTR is needed:STR(VERSION) gives "VERSION" — the literal name, because the argument is stringized before it's expanded. XSTR(VERSION) first expands VERSION to 3, then stringizes, giving "3". That double-layer trick appears constantly in real code.

## — token paste

Glues two tokens into one:

#define CONCAT(a, b) a
#
#b
CONCAT(var, 1) /* → var1     */CONCAT(int_, 32) /* → int_32   */

is how you generate identifiers — used heavily in the X-macro pattern below and in generated dispatch tables.

A combined example — a compile-time assertion:

#define STATIC_ASSERT(cond, msg) \ typedef char static_assert_
#
#msg[(cond) ? 1 : -1]

If cond is false, this declares an array of size -1 — a guaranteed compile error, with msg appearing in the type name so you can see which assertion failed. That's a genuine C89-compatible technique.

(Suggested image: the # operator taking the argument text and wrapping it in quotes, and ## fusing two tokens into one)

Variadic Macros: __VA_ARGS__

C99 added macros that accept a variable number of arguments:

#define LOG(fmt, ...) fprintf(stderr, "[log] " fmt "\n", __VA_ARGS__)

__VA_ARGS__ is replaced by everything after the named parameters, commas included. It's mainly useful for wrapping functions that are themselves variadic — printf, fprintf, snprintf — which is exactly what logging needs:

LOG("count = %d", count);
/* → fprintf(stderr, "[log] " "count = %d" "\n", count) */

Note the string-literal concatenation: "[log] " fmt "\n" works because adjacent string literals are joined by the compiler (fmt arrives as a literal in the common case).

The pre-C23 wrinkle: if __VA_ARGS__ is empty, you get a dangling comma:

LOG("done");
/* → fprintf(stderr, "[log] " "done" "\n", )   ← error! */

The GNU workaround (widely supported, not standard before C23) uses ## to swallow the comma:

#define LOG(fmt, ...) fprintf(stderr, "[log] " fmt "\n", ##__VA_ARGS__)

C23 standardizes __VA_OPT__(...) for this:

#define LOG(fmt, ...) fprintf(stderr, "[log] " fmt "%s\n", __VA_OPT__(,) __VA_ARGS__)

For portable code before C23, the safe approach is to require at least one variable argument, or write two macros (a single-argument version and a variadic version).

(Suggested image: the variadic macro expansion showing VA_ARGS replaced by the trailing arguments, and the empty-argument comma problem marked)

Predefined Macros

The preprocessor comes with a set of macros already defined. These cost nothing and are genuinely useful.

The diagnostic trio is the practical payoff:

#define ERROR(fmt, ...) \ fprintf(stderr, "%s:%d: " fmt "\n", __FILE__, __LINE__, __VA_ARGS__)

That produces compiler-style messages with exact locations, for free:

network.c:142: connection timed out

Platform and compiler detection uses the same machinery — these macros are defined by the implementation:

#if defined(_WIN32)
#define PATH_SEP '\\'
#elif defined(__APPLE__)
#define PATH_SEP '/'
#elif defined(__linux__)
#define PATH_SEP '/'
#else
#error "Unsupported platform"
#endif

Common ones: _WIN32 / _WIN64 (MSVC and MinGW), __linux__, __APPLE__, __unix__, __GNUC__ / __GNUC_MINOR__, __clang__, _MSC_VER. Test with defined(), never by value — the values differ between compilers and none of them means what you'd guess.

And __DATE__/__TIME__ are a build-timestamp trick worth knowing — they let a program report when it was built:

printf("Built %s at %s\n", __DATE__, __TIME__);

The catch: these are fixed at compile time, so they only change when the file is recompiled — not when the program runs. And they make builds non-reproducible, since identical source produces different binaries on different days.

(Suggested image: a source line and the compiler-style diagnostic it produces, with FILE and LINE highlighted as the sources of the path and number)

Conditional Compilation

The directives that make code appear or disappear before compilation:

#if constant-expression
#ifdef NAME
#ifndef NAME
#elif constant-expression
#else
#endif

#ifdef / #ifndef — is this name defined?

#ifdef
_WIN32
#include <windows.h>
#else
#include <unistd.h>
#endif

#ifndef is the same test negated — which is why it's the include-guard directive.

#if — evaluate a constant expression

#if is more powerful: it evaluates a constant integer expression using defined() and the usual arithmetic and logical operators.

#if defined(__STDC_VERSION__) && __STDC_VERSION__ >= 201112L /* C11 or later available */
#define HAVE_ATOMICS 1
#endif

Rules that surprise people:

• Only integer arithmetic. No floating point, no casts, no sizeof, no function calls, and no runtime values. It's evaluated by the preprocessor, which knows nothing about your program.
• Undefined identifiers evaluate to 0. So #if VERSION > 2 is false when VERSION isn't defined — silently, without error. This is a real hazard: a typo'd name gives a false condition rather than a diagnostic. Most compilers warn about this (-Wundef in GCC/Clang), and it's worth enabling.
• defined(NAME) or defined NAME — both forms legal; defined(NAME) is clearer.
• Prefer #if defined(X) over #ifdef X when you need to combine conditions — you can't write #ifdef X && Y. The short-circuit &&/|| in #if is what makes multi-condition tests possible.
• Structural directives must nest properly. Every #if/#ifdef needs its own #endif; #elif and #else must belong to the current level.

#if 0 — commenting out code

The one thing #if 0 does better than /* */: it nests.

#if 0 /* the block comments below would break this if it were       commented out with /* ... *\/ instead                    */ int x = 1;
/* an inner comment */ int y = 2;
#endif

C comments don't nest, so commenting out a region that already contains comments fails. #if 0 ... #endif doesn't care. It's the reliable way to temporarily disable a block — and the preprocessor removes it entirely, so it costs nothing in the translation unit.

#error — fail the build deliberately

#if !defined(__STDC_VERSION__) || __STDC_VERSION__ < 199901L
#error "This program requires C99 or later"
#endif

#errorstops compilation and prints your message. That's exactly what you want for a platform the code can't support, or a required configuration that's missing — it turns hours of confusing downstream errors into one clear statement at the top of the build. #error is standard C. (#warning, which continues compilation, became standard in C23; before that it was a common extension.)

(Suggested image: the conditional-compilation tree — one source file branching into platform-specific regions, with non-taken branches greyed out before the compiler sees them)

Practical Patterns Worth Copying

1. Configurable debug logging

/* debug.h */
#ifndef DEBUG_H
#define DEBUG_H
#ifdef DEBUG
#define DBG(...) do {
    \ fprintf(stderr, "[%s:%d] ", __FILE__, __LINE__);
    \ fprintf(stderr, __VA_ARGS__);
    \ fputc('\n', stderr);
    \
} while (0)
#else
#define DBG(...)((void)0)
#endif
#endif /* DEBUG_H */

Compile with -DDEBUG to enable, without it to compile every DBG(...) call into nothing. Zero runtime cost when disabled, and no #ifdef clutter at the call sites — the calls stay in the source and simply vanish. Note the backslashes continuing the multi-line macro, and that each one must be the last character on its line (no trailing spaces — a trailing space after \ breaks the continuation, which is a genuinely maddening bug).

2. Assertions that vanish in release builds

#include <assert.h>assert(ptr != NULL);
/* calls abort() if false — disabled by NDEBUG */

assert is itself a macro, and <assert.h> defines it to test NDEBUG:

/* what the header effectively contains */
#ifdef
NDEBUG
#define assert(expr)((void)0)
#else
#define assert(expr)((expr) ?(void)0 : __assert_fail(...))
#endif

Compile with -DNDEBUG (or #define NDEBUG before including <assert.h>) and every assertion compiles away. That's why assert must never contain a side effect — assert(scanf("%d", &x) == 1) silently stops reading input in release builds. Use it to check things that must be true, never to do work.

3. Feature flags

#define FEATURE_LOGGING 1
#if FEATURE_LOGGING /* logging code compiled in */
#endif

4. #undef and temporary macros

#undef NAME removes a macro definition, after which the name is an ordinary identifier again. The main uses: overriding a library's macro, and cleanup after a temporary macro — which is exactly what the X-macro pattern requires.

5. X-macros: one list, many expansions

A genuinely elegant advanced pattern. Put a list in a file, then include it repeatedly with different definitions of X:

/* colours.def — the single source of truth */X(RED, 0xFF0000)X(GREEN, 0x00FF00)X(BLUE, 0x0000FF)

/* the enum */typedef enum {
    #define X(name, value) COLOR_
    #
    #name,
    #include "colours.def"
    #undef X
}
Color;
/* the name lookup */const char *colorName(Color c) {
    switch (c) {
        #define X(name, value) case COLOR_
        #
        #name: return
        #name;
        #include "colours.def"
        #undef X
    }
    return "unknown";
}
/* the value table */const unsigned long colorValues[] = {
    #define X(name, value) value,
    #include "colours.def"
    #undef X
};

One list, three generated structures, guaranteed to stay in sync. Add a colour to colours.def and the enum, the name lookup, and the table all update together — the compiler catches any mismatch. This uses everything on this page at once: #include for the list, ## to build identifiers, # to build strings, and #undef for cleanup.

Note the file extension: .def (not .h) signals "this isn't a standalone header — it's meant to be included inside a macro definition."

6. Commenting out a region safely

#if 0 /* disabled code, possibly containing comments */
#endif

7. Guaranteeing a minimum language version

#if defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L /* C99 features available */
#else
#error "C99 or later is required"
#endif

(Suggested image: the X-macro pattern as one list fanning out into three generated structures — enum, switch, table — with a "stay in sync automatically" label)

What the Preprocessor Cannot Do

Understanding the limits explains why some problems have no macro solution:

The practical takeaway: when a macro keeps getting more complicated — layers of parentheses, ## gymnastics, argument-count tricks — that's the signal to write a function, a static inline helper, or a code generator instead. Macros are a blunt instrument and they don't get sharper with effort.

(Suggested image: the "cannot" list as a boundary diagram — preprocessor capabilities on one side, compiler capabilities on the other, with the shared token stream in the middle)

Common Mistakes

1. Missing parentheses around macro parameters — #define SQUARE(x) x*x gives SQUARE(1+2) == 5, verified above. Wrap every parameter.
2. Missing parentheses around the whole macro body — DOUBLE(x) as (x)+(x) breaks when composed: 2 * DOUBLE(3) becomes 9, not 12.
3. Passing arguments with side effects — MAX(i++, j++) incremented jtwice and performed 3 increments total, verified above. Undefined behavior, invisible at the call site.
4. Writing a multi-statement macro without do { } while (0) — an if without braces followed by ; orphans a later else and fails to compile.
5. A space between the macro name and ( — #define F(x) is function-like; #define F (x) is an object-like macro with body (x). Completely different.
6. Forgetting include guards — the second inclusion produces duplicate definitions; verified as 2 copies of typedef struct instead of 1.
7. Guard-name collisions across headers — the second header's contents silently vanish because the first already defined the guard name.
8. Using a leading underscore in a guard name — reserved for the implementation.
9. Assuming #pragma once is portable — it's a widely supported extension, not standard, and it keys on file path, so two paths to one file can still double-include.
10. Expecting macros to respect scope — a #define inside a function body still applies for the rest of the file.
11. Expecting macro names to expand inside string literals — they don't; "VERSION" stays literal.
12. Using a runtime expression in #if — #if needs a constant integer expression; no sizeof, no casts, no functions, no floats.
13. Relying on undefined identifiers being errors in #if — they evaluate to 0, silently. Enable -Wundef.
14. Writing #ifdef A && B — invalid; use #if defined(A) && defined(B).
15. Trailing spaces after a \ line continuation — breaks the macro with a confusing error at an unrelated line.
16. Omitting the semicolon conventions — an object-like macro shouldn't carry one (#define MAX 100; breaks arr[MAX];), and function-like macros are used with one.
17. Passing a comma-containing argument — MAX(a ? b, c : d, e) splits wrongly, because the preprocessor splits on commas and doesn't understand the ternary. Wrap it: MAX((a ? b : c), e).
18. Using macros where a function would be safer — no type checking, no debugging, and double evaluation are all avoided by a function or static inline.
19. Redefining a macro with a different body — a diagnostic (or silent use of the first definition) depending on the compiler.
20. Confusing #define with assignment — there's no storage, no address, and no runtime existence. &MAX and MAX++ are errors.

(Suggested image: "20 Preprocessor Mistakes" checklist — with #1, #3, and #5 highlighted as the ones that produce silently wrong results)

Final Thoughts

The preprocessor is a text editor that runs before your compiler. Everything about it follows from that one fact: #include pastes a file, #define substitutes text, conditionals remove text, and none of it knows or cares about C's types, scope, or syntax.

Once you internalize that, the whole topic becomes predictable:

• #include is textual insertion — which is why double inclusion is a problem, and why include guards (or #pragma once) are mandatory
• Macros are text substitution — which is why parentheses are non-negotiable, why arguments can be evaluated more than once, and why #define SQUARE(x) x*x gives 5 for SQUARE(1+2)
• Multi-statement macros need do { } while (0) so they behave as one statement everywhere
• Conditional compilation removes code before the compiler sees it — the tool for platform differences, debug builds, and feature flags
• __FILE__, __LINE__, __DATE__, and __VA_ARGS__ cost nothing and are already there — use them for diagnostics

The judgement that matters most is knowing when to stop. Macros are powerful precisely because they're unconstrained — and that's also why they're dangerous. Use them for what only they can do: constants, conditional compilation, and the handful of genuinely textual operations like #, ##, and sizeof-based idioms. For everything else, write a function and let the compiler help you.

And when a macro misbehaves, remember the debugging move from the top of this page: gcc -E. The answer is always visible in the expanded translation unit — usually in five seconds.