C — Cradle to Mastery

C was created at Bell Labs in the early 1970s so UNIX could be rewritten in something more portable than assembly. That single decision is why C's fingerprints — and often its actual compiled code — sit underneath Linux, Windows, every major database, and the runtime of nearly every higher-level language you have used.

There is no single official C toolchain the way there is with some newer languages: GCC and Clang are both free, both mature, and both genuinely used in production, with mostly-compatible command-line flags. Getting one installed and a first file compiled is the entire goal of this lesson.

C's standard guarantees only *minimum* sizes for its integer types, not exact ones — <code>int</code> is at least 16 bits, in practice almost always 32, but the standard never promises that. This portability-over-precision tradeoff runs through the whole type system and is worth internalizing early.

C had no dedicated boolean type until C99's <code>_Bool</code> (later renamed <code>bool</code> via a header). Before and often still after that, <code>0</code> means false and anything nonzero means true — a convention that shows up constantly in real C code and is worth being fully comfortable with.

C has no pass-by-reference parameters: every argument is copied by value into the function, full stop. The only way for a function to modify a caller's variable is for the caller to explicitly pass that variable's address, which the function receives as a pointer — the idea the rest of the course builds on.

There is no separate string type in C at all: a string is a <code>char</code> array that happens to end with a zero byte, and every standard string function relies on that convention being upheld. Forgetting the terminator, or writing past the array's bounds, is one of the most common real C bugs.

Unlike some languages, the C standard makes no guarantee that a compiler will optimize tail-recursive calls into a loop. A recursive function that looks clean on paper can genuinely overflow the call stack in C where an equivalent function in another language would not, which is worth knowing before you rely on it.

C has no exception mechanism: every function that can fail signals it through a return value, an out-parameter, or the global <code>errno</code>, and checking that signal after every single call is entirely the programmer's responsibility. Skipping a check is how real C bugs are born.

A pointer is just a variable holding a memory address, but that simplicity is deceptive: dereferencing, pointer arithmetic, and the stack/heap distinction combine into the single idea that separates C from almost every language you'll learn afterward. This lesson is the foundation the rest of the stage builds on.

<code>malloc</code> and <code>free</code> hand memory-management responsibility entirely to you — there is no garbage collector watching for memory you forgot to release. A leak in a long-running C program accumulates silently until it genuinely exhausts available memory.

Where the <code>const</code> keyword sits in a pointer declaration changes what it actually protects — a pointer to constant data reads completely differently from a constant pointer to mutable data, and mixing them up is a classic beginner mistake. <code>volatile</code> solves an entirely separate problem.

A compiled function's code sits at a memory address just like any other data, and C lets you store that address in a variable and call through it later. This is the mechanism behind callbacks, dispatch tables, and every plugin-style API C code has ever offered.

The C compiler will happily accept code that reads freed memory or writes past an array's end — it has no obligation to catch either. Valgrind and AddressSanitizer are separate, genuinely different tools that instrument a running program to catch exactly these bugs at runtime instead.

A raw segmentation fault gives you almost no information by itself: which line, which pointer, which call led there. GDB is how you actually answer those questions — breakpoints, stepping, and inspecting a crashed program's stack and variables directly.

This lesson is the synthesis for the stage: the specific ways C code can invoke undefined behaviour &mdash; buffer overflows, use-after-free, signed integer overflow, unsequenced expressions &mdash; and how the pointer, memory-allocation, and tooling lessons above combine into one coherent defensive practice. Read it once each piece is familiar on its own.

Unlike some languages' enums, a C <code>enum</code> is nothing more than a set of named integer constants — any <code>int</code> value, including ones with no matching name, can be assigned to an enum variable without complaint from the compiler. Knowing this prevents a false sense of type safety.

A <code>union</code>'s members all overlap the same block of memory, so writing through one member and reading through another is a real, sometimes genuinely useful technique — and also a common source of subtle bugs when the active member isn't tracked carefully.

A linked list is the classic proof that structs and pointers combine into something bigger than either alone: a struct holding a pointer to another instance of its own type, chained together one allocation at a time. Building one by hand is the single most common way this idea gets internalized.

This lesson is the synthesis for the stage: struct definition and member access, <code>typedef</code> for readability, nested structs, how arrays decay to pointers when passed to a function, <code>sizeof</code>'s behavior on each, strings as char arrays, and function pointers as struct members &mdash; all of it combined into the kind of data-modeling code real C projects actually contain.

There is no module system underneath C's <code>#include</code>: it is a literal, unconditional text-substitution that pastes the named file's contents into yours before real compilation even starts. Understanding this explains include guards, forward declarations, and a surprising number of build errors.

A real C project splits code across multiple <code>.c</code> files, each compiled independently into its own object file, with the linker combining those object files into one executable only at the very end. This two-stage model is why a forward declaration in a header is enough to compile against code defined elsewhere.

Make automates rebuilding only what actually changed, based on file timestamps and the dependency rules you write — but its syntax is unforgiving about one specific thing: recipe lines must be indented with a literal tab character, and a stray space there produces a notoriously confusing error.

The preprocessor handles <code>#include</code>, <code>#define</code>, and conditional compilation directives as a pure text-substitution pass, entirely before the compiler proper ever sees your code. A macro missing parentheses around its parameters is a classic, genuinely real bug this lesson explains how to avoid.

C's six bitwise operators — AND, OR, XOR, NOT, and the two shifts — manipulate individual bits directly, which is exactly what flag combinations, bitmasks, and direct hardware register access all require. This is a genuinely low-level tool most higher-level languages hide from you entirely.

<code>printf</code>'s ability to accept any number of arguments of varying types is not a compiler special case: it is built on <code>stdarg.h</code>'s macros, which any C function can use to accept its own variable-length argument list the same way.

C's standard library is intentionally minimal compared to most modern languages — stdlib.h, ctype.h, math.h and a handful of others cover only what the standard considers genuinely universal, leaving everything else to third-party libraries or the operating system directly.

C's file I/O functions — <code>fopen</code>, <code>fread</code>, <code>fwrite</code>, <code>fclose</code> — predate nearly every other language's own file APIs, and most of those later APIs are themselves thin wrappers around similar underlying system calls. Learning these four functions well pays off widely.

C11 technically standardized <code>&lt;threads.h&gt;</code>, but in practice almost every real C codebase reaches for POSIX threads (pthreads) instead, since it predates the standard, is more widely supported, and is what existing code and tutorials already use.

C's standards history runs from K&R's original 1978 book — never itself a formal standard — through ANSI C89/C90, C99, C11, C17, and now C23, each a genuinely different, ratified version with its own feature set. Knowing which era a piece of code targets explains a lot about why it looks the way it does.