rust1-1 opened by naming the tradeoff Rust refuses to accept: manual-control performance without manual-control memory bugs. C is the language that tradeoff was named against — no garbage collector, no borrow checker, no compiler enforcing safety at all. Just the programmer, trusted completely. This course starts exactly where that trust begins.

The Compile-Then-Link Model

C has no virtual machine and no interpreter — source code becomes a real, standalone executable in two genuinely separate steps. Compilation turns each .c file into an object file (machine code, but not yet a runnable program). Linking then combines every object file, plus any libraries being used, into one final executable. A single gcc command usually runs both steps back to back — but they remain conceptually distinct, and Chapter 5 of Course 2 (Multi-File Projects) is built entirely around treating them as such.

Installing a Compiler: gcc and clang

Unlike Rust's rustup — one official installer managing one official toolchain — C has no single canonical compiler. gcc (GNU Compiler Collection) and clang (LLVM's compiler) are the two most common; both compile standard C, both are genuinely widely used, and neither is "more official" than the other the way rustc is for Rust.

The Smallest C Program

#include <stdio.h> pulls in the standard I/O library's declarations — printf isn't a language keyword, it's an ordinary library function, declared in that header. int main() is the entry point, same role as Rust's fn main() — but notice the explicit return 0;: C's main reports a real exit status back to the operating system, and leaving it out (pre-C99) was undefined behavior, a theme this course returns to often.

Compiling & Running

There is no single-command equivalent of cargo run or go run — compiling and running are always two separate commands. -o hello names the output executable explicitly.

No Built-In Package Manager or Build Tool

This is the first real toolchain difference from both Rust and Go. Go's toolchain is minimal but complete — go build handles everything. Rust bundles even more into cargo — building, dependencies, testing, all official. C has none of this as an official standard: no built-in package registry, no single blessed build tool. Third-party tools like make (Course 2's own Chapter 5) and CMake exist and are genuinely widely used — but nothing plays the role cargo plays for Rust. This isn't an oversight; C predates the very idea of a language-integrated package manager by decades.

Coding Challenges

Chapter 1 showed C trusting the programmer with the toolchain itself. This chapter shows the same trust applied to something Rust and Go both nail down precisely: how big a number actually is.

Declaring Variables

type name = value; — no let, no var, no inference. Every variable's type is written explicitly, every time.

The Basic Types

• int — a whole number
• float — single-precision floating point
• double — double-precision floating point, the default for real work
• char — a single byte, holding a small integer that's interpreted as a character (there is no separate "character" type underneath — char genuinely is a small integer)

sizeof and Why Type Sizes Aren't Fixed

This is the chapter's real subject. In Rust, i32 is exactly 32 bits, everywhere, by definition — the type's name states its size as a language guarantee. In C, the standard only guarantees minimums: int is guaranteed to be at least 16 bits, but is commonly 32 bits on today's platforms — "commonly," not "guaranteed."

Writing genuinely portable C — code that behaves identically across every platform — means never assuming int is exactly 4 bytes, something Rust or Go code never has to worry about at all.

Fixed-Width Types via <stdint.h>

C99 added exactly the guarantee Rust and Go bake in by default — opt-in, not automatic.

Signed vs. Unsigned

Every integer type has a signed (default) and unsigned variant. This distinction hides a genuine asymmetry worth flagging now, well before Course 3's Undefined Behavior chapter covers it in full: unsigned overflow is well-defined — it wraps around (UINT_MAX + 1 becomes 0). Signed overflow is undefined behavior — the standard makes no promise about what happens at all, not even wraparound.

Coding Challenges

Chapter 2 showed the standard being deliberately vague about integer sizes. This chapter shows the same looseness applied to something even more fundamental — what counts as "true."

Arithmetic, Comparison & Logical Operators

The familiar set — + - * / %, == != < > <= >=, && || ! — behaves mostly as expected, with one early trap: dividing two integers truncates, it doesn't round.

No True Boolean Before C99

This is the real subject of the chapter. Original C had no boolean type at all. Truth was just an int: 0 means false, any nonzero value means true — including negative numbers. Every if, every while, every logical expression in classic C evaluates to a plain integer, not a distinct boolean value the way Rust's bool always has been.

<stdbool.h> in Modern C

C99 added bool, true, and false — but even now, they're not a genuinely new primitive the way Rust's bool is. Under the hood, bool is a macro for _Bool (an integer type that can only hold 0 or 1), and true/false are just 1 and 0 in disguise.

if / else

Because truth is just "nonzero," C allows any expression as a condition — not just a genuine comparison.

This flexibility hides a classic, still-common bug: writing = (assignment) where == (comparison) was meant. if (x = 5) compiles cleanly, assigns 5 to x, and the condition is then "is 5 nonzero" — always true.

switch

Cases fall through by default — execution continues into the next case unless an explicit break stops it. Rust's match arms never fall through; each one is fully self-contained.

Coding Challenges

Loops are one of the few places C's syntax and Rust's genuinely diverge in shape, not just in guarantees. This chapter covers all three C loop forms and where each one's closest Rust equivalent actually is.

The Three-Part for Loop

Init, condition, and increment, all in the parentheses. Rust has no equivalent syntax at all — Rust's own for only ever iterates over a range or an iterator (for i in 0..5), never a raw three-part counter. C's version is lower-level: nothing stops the counter, the bound, or the step from being anything at all.

while and do-while

while checks its condition before the first iteration — the body might never run. do-while checks after — the body always runs at least once. Rust has no do-while construct at all; the closest equivalent is a plain loop { ... if !condition { break; } }, spelled out manually rather than given its own keyword.

break and continue

Same meaning as in Rust — break exits the loop immediately, continue skips straight to the next iteration.

Loop Variable Scope: C89 vs. C99

Genuinely older C (C89) required loop counters to be declared before the loop, since variable declarations had to appear at the top of a block — for (int i = ...) wasn't legal syntax at all. C99 relaxed this, allowing the now-familiar in-loop declaration. Legacy C codebases still sometimes show the older style; recognizing it matters when reading real, older C.

Infinite Loops

C has no dedicated keyword for "loop forever" — the idiom is for (;;) or while (1), both relying on an empty or always-true condition. Rust's loop keyword states the same intent explicitly and self-documentingly, rather than as a side effect of an empty condition.

Coding Challenges

Chapter 1 briefly used main without explaining what makes a function "known" to the compiler. This chapter covers that directly — and sets up the exact problem pointers exist to solve next.

Function Syntax

Declarations vs. Definitions

A declaration (or prototype) tells the compiler a function exists and its exact signature — return type, name, parameter types — without providing a body. A definition provides the actual body. C compiles top to bottom in a single pass: calling a function before the compiler has seen either its declaration or its definition is an error. Rust, by contrast, allows calling any function defined anywhere in the same module, in any order — no forward declaration needed.

Header Files

A .h file conventionally holds declarations, shared across multiple .c files via #include — the mechanism that lets one source file call a function defined in a completely different one. Course 2's Multi-File Projects & Makefiles chapter covers this in full; for now, know that a header is essentially a shared table of "these functions exist, here are their signatures."

Pass-by-Value by Default

Function arguments are copied into the function — modifying a parameter inside the function has no effect on the caller's original variable. This is genuinely worth a three-way comparison: Go is also pass-by-value by default, exactly like C — a rare point of agreement between the two. Rust is the outlier, requiring an explicit choice: pass by value (moves or copies), or pass a reference (&T/&mut T) deliberately.

Simulating Pass-by-Reference With Pointers

To let a function genuinely modify the caller's variable, C requires passing a pointer explicitly — the caller's address, not its value. This is exactly what the very next chapter covers in depth; for now, just recognize that "I need the function to change my variable" is the specific problem pointers solve.

Coding Challenges

Every chapter so far has shown small toolchain and syntax differences from Rust. This one is different — arrays are where C's total absence of a safety net becomes something you can actually see happen.

Declaring & Initializing Arrays

A plain C array has a fixed size, known at compile time — genuinely comparable to Rust's own fixed-size [T; N] array (not Vec, which can grow). Both languages have this exact concept. What happens when you go past the end is where they stop agreeing.

No Bounds Checking — The Real Difference

Accessing values[10] on a 5-element array is not an error in C. It's not a panic. It compiles, it runs, and it reads or writes whatever memory happens to sit past the array — memory that belongs to something else entirely. Rust's [T; N], by contrast, checks every index access at runtime and panics on an out-of-bounds index — a controlled, visible failure instead of silent memory corruption.

A Concrete Demonstration

Two adjacent local variables often sit next to each other in memory. Writing past the end of one array can silently overwrite the other — no error, no warning, just a value that changed for no visible reason.

Course 2's Memory Bugs chapter covers this class of problem in full, with real tooling (valgrind) to catch it. For now, the point is simpler: C genuinely will not stop this.

Array-to-Pointer Decay, Previewed

Chapter 5 established pass-by-value as C's default. Arrays quietly break that rule: passing an array to a function actually passes a pointer to its first element, not a copy of the whole array. Chapter 7 covers pointers in full — this is just naming the exception now, so it doesn't feel unexplained later.

Getting the Array's Size

sizeof(arr) / sizeof(arr[0]) computes the element count — but only where the array was actually declared. Once it decays to a pointer (inside a function it was passed to), sizeof on the parameter gives the pointer's size, not the array's.

Coding Challenges

Chapter 5 needed a pointer to let a function modify a caller's variable. Chapter 6's arrays turned out to already secretly be pointers. This chapter finally names the mechanism directly — and closes the loop this whole course opened back in Chapter 1.

What a Pointer Actually Is

A pointer is a variable whose value is a memory address. & (address-of) gets a variable's address; * (dereference) accesses the value stored at an address.

Why C Needs Pointers

• Simulating pass-by-reference — Chapter 5's own unsolved problem: pass &x instead of x, and the function can modify the caller's variable through the pointer
• Working with arrays — Chapter 6's decay is pointer usage; every array access secretly goes through this exact mechanism
• Dynamic memory — Course 2's central chapter; memory allocated at runtime is only ever reachable through a pointer

Pointer Arithmetic

p + 1 doesn't advance by one byte — it advances by sizeof the pointed-to type. This is exactly what makes array indexing work: arr[i] is literally defined as *(arr + i), the same operation spelled two different ways.

The Null Pointer & Dereferencing It

NULL represents "points at nothing." Dereferencing a null (or uninitialized) pointer is undefined behavior — typically a crash, but never guaranteed. Rust's safe code has no null pointers at all — Option<T> replaces the entire concept, forcing an explicit check before any value can be used, eliminating this bug category by design rather than by convention.

What Rust's Borrow Checker Exists to Prevent

Here's the real payoff. A dangling pointer is a pointer to memory that's already been freed, or has gone out of scope — the pointer still looks perfectly valid, but what it points to is gone. C lets you create and use one freely; it's simply undefined behavior. Rust's borrow checker makes this a compile error — the program literally won't build if a reference could ever outlive the data it points to. This is the exact mechanism Rust's own course named as its founding goal back in rust1-1, and it's this specific bug class it exists to eliminate.

Coding Challenges

C has no dedicated string type. Everything Chapters 6 and 7 covered — fixed-size arrays, no bounds checking, pointer arithmetic — applies directly to text, exactly as-is. This closing chapter of Course 1 is where those two chapters' consequences become the most historically significant.

Strings Are char Arrays

A string is just an array of char, nothing more.

Null Termination

The '\0' byte marks the end. There is no separate length field anywhere — C strings carry no length of their own. Rust's String stores its length directly, alongside the data; finding a C string's length means scanning forward until '\0' is found, an O(n) operation every single time, unlike Rust's O(1) length lookup.

String Literals vs. Char Arrays

A real, important distinction: char *s = "hello" points at a string literal, which may live in read-only memory — writing through s is undefined behavior. char s[] = "hello" copies the characters into a genuinely mutable local array.

string.h Functions

strcpy vs. strncpy — The Classic Buffer Overflow

strcpy copies a string with zero bounds checking — exactly Chapter 6's array-overflow problem, applied specifically to text. Copying a longer string into a smaller buffer silently writes past its end. This single mistake is one of the most historically significant vulnerability classes in software security.

strncpy takes a maximum length and is safer — but has its own genuine gotcha: if the source is at least n characters long, strncpy does not guarantee the result is null-terminated at all.

Coding Challenges