Course 1 covered scalars, arrays, and the pointers connecting them. Course 2 opens with C's way of grouping several values into one — and, in the same chapter, its way of letting several values share one.

Declaring & Using Structs

typedef

Referring to struct Point everywhere gets verbose fast. typedef gives the type a shorter name — an idiom so common in real C that it's effectively the default style.

Rust never needed this ceremony — a struct's own name is always the type, directly, with no separate aliasing step required.

Structs Are Pure Data

A C struct has no methods attached to it — no impl block equivalent from Rust. Any function operating on a struct is written separately, typically taking a pointer to it as a parameter. Course 2's own Function Pointers chapter (Ch.7) later shows one way C approximates method-like dispatch without a language feature for it at all.

Unions

A union looks like a struct syntactically, but its members share the same memory — only one is genuinely "active" at a time. A union's sizeof equals its largest member's size, not the sum of all members, unlike a struct.

The Danger of Type Punning via Unions

Reading a union member that wasn't the one last written is, in most cases, undefined behavior — the union itself carries no record of which member is currently valid. Compare this directly to Rust's own data-carrying enums (rust1-6): a Rust enum stores a hidden discriminant tracking which variant is actually active, so accessing the wrong one is caught as a compile-time type error through match, not silently allowed at runtime. A C union tracks nothing at all — the programmer is expected to remember.

Coding Challenges

c1-7 named dangling pointers as the exact bug class Rust's borrow checker exists to prevent. This chapter shows where those dangling pointers actually come from — and hands you the same responsibility Rust's ownership system otherwise carries for you.

Stack vs. Heap

The stack is automatic: a local variable's memory exists for exactly as long as its function is running, freed the instant that function returns — this is precisely what made returning &local_var in c1-7 a dangling pointer. The heap is manual: memory allocated there exists until something explicitly releases it, with no connection to any particular function's lifetime, and effectively unlimited size.

malloc

Allocates raw, uninitialized memory of a given byte size, returning void * — cast or assigned to a typed pointer. On failure, it returns NULL, which must always be checked; Rust, by contrast, typically aborts automatically on allocation failure rather than returning a value the caller might forget to verify.

calloc

Like malloc, but zero-initializes the memory, and takes element count and element size as two separate arguments. The zero-init distinction genuinely matters — malloc's memory is garbage until written, and reading it before initializing is its own class of bug.

realloc

Resizes a previous allocation — and may move it to an entirely new address. The returned pointer can genuinely differ from the one passed in, and the old pointer becomes invalid the instant realloc succeeds.

free

Releases heap memory back to the system. Immediately afterward, the pointer that referenced it becomes a genuine dangling pointer — this is the exact mechanism c1-7 warned about, closing the loop directly: freeing is how dangling pointers are most commonly created in real code.

Manual Memory Management vs. Rust's Ownership

This is the chapter's real subject. In C, you decide when to call free, and nothing enforces it. Forget it — a leak. Call it twice on the same pointer — a double-free, undefined behavior. Use the pointer after freeing — use-after-free, also undefined behavior. Rust's ownership model (rust1-3) tracks, at compile time, exactly when a value's owner goes out of scope, and automatically inserts the equivalent of free at precisely that point — no leaks in safe code, no double-frees, no use-after-free, guaranteed by the compiler rather than the programmer's own discipline. Every rule this chapter just described by hand is what Rust's ownership system enforces silently, every time, without exception.

Coding Challenges

Every bug this chapter names has already appeared somewhere in this course — c1-6's buffer overflow, c1-7's dangling pointer, c2-2's leaks and double-frees. This chapter gathers them into one catalog, and introduces the tools real C developers actually use to catch them.

The Bug Catalog, Named Precisely

• Use-after-free — dereferencing a pointer after its memory was freed (c1-7, c2-2)
• Double-free — calling free twice on the same allocation (c2-2)
• Memory leak — allocated memory that's never freed, with no remaining pointer to it at all (c2-2)
• Buffer overflow — reading or writing past an array or allocation's actual bounds, stack or heap (c1-6, c1-8)
• Uninitialized read — reading memory (from malloc, or a declared-but-unset variable) before anything was written to it

A Genuine Leak Example

Each call leaks a small, fixed amount — individually harmless-looking, but accumulating without bound. Rust makes this specific pattern impossible: a value's Drop runs automatically the moment its owner goes out of scope, with no equivalent "forgot to call it" failure mode in safe code.

valgrind

A dynamic analysis tool — run an already-compiled program under it, no recompilation needed. It reports leaks, invalid reads/writes, and use-after-free, each with a stack trace showing exactly where the bad allocation, access, or free occurred.

AddressSanitizer (ASan)

A compile-time instrumentation approach — add -fsanitize=address and recompile. It catches much of the same bug class, but faster than valgrind, and crashes immediately with a detailed report at the exact moment the bad access happens, rather than only summarizing at program exit.

Why This Chapter Exists

This is the honest cost of the tradeoff Chapter 1 named: C's speed and control come with these exact bug classes as a genuine, permanent possibility — not a temporary tooling gap that will eventually be fixed. Rust's compiler catches most of this entire category at compile time, before the program ever runs. C requires catching it at runtime, with tools like these, ideally before shipping — a real and lasting asymmetry between the two languages, not a difference in maturity or polish.

Coding Challenges

#include <stdio.h> has appeared in nearly every example since Chapter 1. This chapter finally explains what it — and every other line starting with # — actually does.

The Preprocessor Runs Before Compilation

The preprocessor is a genuinely separate pass: pure text substitution over the source file, completed entirely before parsing or type-checking ever begins. Rust has no preprocessor at all — its macro system (rust3-4) operates on the actual parsed syntax tree, with real awareness of types and structure, not raw text. This is a fundamental difference in kind, not just syntax.

#define — Object-like Macros

Every occurrence of MAX_SIZE in the file is replaced, textually, with 100 — before the compiler ever sees it as a number. No type checking happens at this stage at all.

#define — Function-like Macros

Looks like a function; is pure text substitution. Without full parenthesization, this breaks badly:

Even with correct parentheses, macros carry a trap no real function has: arguments can be evaluated more than once.

#include

Now the honest explanation: #include pastes the entire contents of the named file, textually, in place of the #include line itself — nothing more sophisticated than that. It's not an "import" in Rust's sense at all; there's no module system underneath, just literal text insertion before compilation.

Header Guards

Including the same header twice — common once a project has several source files each including several headers — pastes its contents twice, causing duplicate definitions and a real compile error. The classic fix:

The modern, widely-supported alternative is a single line:

Rust's module system has no equivalent problem at all — use never textually pastes anything, so there's nothing to accidentally duplicate.

Conditional Compilation

#ifdef/#ifndef/#if/#else/#endif compile different code depending on which macros are defined — commonly used for platform-specific code, or separating debug and release builds.

Coding Challenges

c1-1 named the gap directly — no official build tool. c1-5 introduced header files in passing. c2-4 explained exactly what #include does. This chapter puts all three together, for real, on a genuine multi-file project.

Why Split a Project Across Files

Organization at real scale, and something more practical: faster rebuilds. Recompiling one changed file is far cheaper than recompiling an entire project from scratch every time — but only if the build process actually takes advantage of that.

Header Files as Contracts

A header declares what a source file provides, without exposing how. Per c2-4's literal explanation, those declarations get pasted, verbatim, into every file that includes the header — giving each one enough information to call the functions without ever seeing their implementation.

Separate Compilation

This is c1-1's compile-then-link model, made concrete across multiple files. Each .c file compiles independently into its own object file (.o); only afterward are all the object files linked into one executable.

A Worked Example

The Linking Step, In Detail

main.o contains a call to add() with no body — an unresolved external symbol. math_utils.o contains add()'s actual definition. The linker's job is matching them up. Forget to link math_utils.o in at all, and the result is one of C's most recognizable real-world errors:

A Real Makefile

make is the unofficial-but-standard answer to c1-1's own open question — targets, dependencies, and rules, rebuilding only what actually changed.

Run make, and it rebuilds only the files whose dependencies (listed after the colon) are newer than their target — editing only math_utils.c recompiles just that file and re-links, leaving main.o untouched.

Coding Challenges

Every program so far has lived entirely in memory. This chapter opens the door to the filesystem — and introduces a resource-management discipline that should already feel familiar from c2-2's malloc/free pairing.

Opening a File

File Modes

The mode string controls both direction and format: "r" read, "w" write (truncating), "a" append — each with a b variant ("rb", "wb", "ab") for binary.

Text Mode vs. Binary Mode

Text mode may translate line endings depending on the platform — on Windows, \n can be translated to/from \r\n on read/write. Binary mode transfers bytes exactly as-is, with no translation at all. This is genuinely platform-dependent behavior, worth knowing explicitly rather than discovering by accident. Rust's std::fs has no equivalent mode distinction at the language level — it's byte-oriented by default, with no automatic translation to opt out of.

Reading & Writing Text

fgets takes a maximum buffer size, exactly the bounds-checking discipline c1-8 covered. Its predecessor, gets(), took no size argument at all — it was so fundamentally unfixable that C11 removed it from the standard entirely.

Reading & Writing Binary Data

fread/fwrite operate on raw bytes: a pointer, the size of each element, and how many elements. Both return the actual number of items transferred — which can genuinely be less than requested, and isn't automatically an error condition to ignore.

Closing a File

Flushes any buffered writes and releases the underlying OS file handle. Forgetting it is the same class of mistake as c2-2's forgotten free — a resource acquired manually that must be released manually, just a file descriptor instead of heap memory.

Coding Challenges

c2-1 named this chapter directly: "one way C approximates method-like dispatch without a language feature for it at all." Course 2 closes by actually building that mechanism — the same one every object-oriented language's runtime dispatch is quietly built from underneath.

Function Pointer Syntax

A pointer to a function taking two ints and returning int. The parentheses around *operation are mandatory — without them, this parses as something else entirely, a genuine syntax trap worth memorizing rather than re-deriving each time.

Assigning & Calling Through a Function Pointer

A function name decaying to a pointer to itself is genuinely the same phenomenon as array-to-pointer decay from c1-6, just applied to functions instead of arrays.

Callbacks

Passing a function pointer so another function can call it later — a real, common C idiom.

A Simple vtable-Style Dispatch Pattern

The real payoff: store a function pointer alongside data, and let different instances point at different implementations.

A second shape type populates its own struct's function pointer with a different implementation entirely — calling shape->area(shape) dispatches to the correct one, purely because the pointer was set to point there.

What C++ and Rust Formalize

This is not just an analogy — it's the literal mechanism. A C++ class with virtual methods, and Rust's own dyn Trait, both work by storing a table of function pointers alongside the data, dispatched through one level of indirection — exactly what was just built by hand above. The difference is who manages the table: here, the programmer wires it up manually and must get it right; in C++ and Rust, the compiler generates the table automatically and guarantees it's always fully and correctly populated.

Coding Challenges