How to Read This Curriculum

This is not a book you skim. It is a curriculum you execute.

Why This Matters

You already know how to program. You understand variables, functions, loops, data structures, and the idea of a type system. That knowledge is useful here, but it is also dangerous: it will make C look familiar in ways that mislead you. C shares syntax with many languages but shares semantics with the machine.

This document is built so that each concept appears only after you have the prerequisites to actually understand it. The single most important instruction is: do not skip prerequisites. When a section says it depends on something, it means the explanation will not fully make sense without it.

What This Document Is

• A dependency-ordered curriculum.
• A long-term reference you can re-enter at any point.
• A project-driven path: you will build things, not just read about them.

What This Document Is Not

• A beginner programming course.
• A keyword list or shallow cheat sheet.
• A collection of disconnected tutorials.
• A textbook that spends twenty pages explaining what a variable is.

The reader is assumed to already understand programming. This document focuses on what is *different*, *subtle*, *dangerous*, *powerful*, and *performance-relevant* in C.

How the Curriculum Is Organized

The curriculum is split into dependency layers called parts:

1. Part 0 — Orientation. What C is, what it is not, and how to read this. 2. Part 1 — The Core Language. Everything ISO C defines: types, expressions, control flow, functions, pointers, arrays, structs, the preprocessor, and multi-file programs. 3. Part 2 — The Object Model and Undefined Behavior. How C actually behaves in memory, and the exact boundary between defined and undefined behavior. 4. Part 3 — The Standard Library. The ISO C library, header by header. 5. Part 4 — Memory Management. The heap, ownership, allocators, and virtual memory. 6. Part 5 — Compilation, Linking, and Building. From source to executable. 7. Part 6 — Debugging and Optimization. Finding bugs and making code fast. 8. Part 7 — CPU Architecture and Assembly. How C maps to the machine. 9. Part 8 — Data Structures and Algorithms. Standard structures built in idiomatic C. 10. Part 9 — Performance. Locality, data layout, SIMD, profiling. 11. Part 10 — Concurrency. Threads, atomics, and the C memory model. 12. Part 11 — Operating System Programming. Platform-specific systems work. 13. Part 12 — Networking. Sockets and protocol engineering. 14. Part 13 — Embedded C. Microcontrollers, MMIO, interrupts. 15. Part 14 — RTOS. Real-time operating system concepts. 16. Part 15 — Security. Attacks and defenses in C systems. 17. Part 16 — Graphics, Audio, Databases. C's role in domain software. 18. Part 17 — FFI and Interop. Calling C from other languages and vice versa. 19. Part 18 — Compiler Development. Building a compiler in C. 20. Part 19 — Linkers, Loaders, Executable Formats. The full picture below the source. 21. Part 20 — Project-Based Mastery. Twenty-five projects that force you to apply everything. 22. Part 21 — Final Master Reference. Compact reference sections.

A Critical Distinction: What Is "C"?

The word "C" is overloaded. Throughout this document, the following are kept deliberately separate:

This matters because most real-world C programming mixes these layers. You must never mistake a platform API for ISO C. When this document says something is POSIX, it is POSIX. When it says something is ISO C, it is guaranteed by the standard on every hosted implementation.

The Standard-Version Baseline

The primary practical baseline is C17. When behavior differs between C89/C90, C95, C99, C11, C17, and C23, the text says so explicitly. C23 features are labeled C23 and are never presented as universal C.

The Mastery System

Reading is not mastery. Every concept is tracked against eight levels:

Most sections target a specific level. The ## Progress section at the end of each chapter lets you record where you actually are.

The Badge System

Badges classify content so you can filter it. They always mean the same thing:

A full taxonomy with filtering rules is in architecture/BADGE_TAXONOMY.md.

How to Work Through a Chapter

Every major concept follows a predictable structure. Not every section applies to every concept, but major ones use this order:

1. Why This Matters — why you should care. 2. Prerequisites — what you must already understand. 3. Core Concept — the idea itself. 4. Syntax — the exact form. 5. Examples — minimal, normal, realistic, advanced, and dangerous examples. 6. How It Works — what happens in memory or in the compiler. 7. Variations — the different forms. 8. Common Mistakes — what people get wrong. 9. Undefined Behavior — where the standard gives no guarantee. 10. Portability — where implementations legitimately differ. 11. Under the Hood — compiler, linker, or hardware behavior. 12. Practical Usage — where this shows up in real systems. 13. Exercises — targeted practice. 14. Deep Challenge — expert-level problems. 15. Related Concepts — cross-links. 16. References — authoritative sources. 17. Verification — accuracy status of the claims. 18. Progress — checkboxes and mastery level.

How to Use the Code Examples

Code examples state, wherever possible:

• The C standard they target.
• The compiler and platform assumptions.
• Expected output.
• Whether they were actually compiled and run.

If a claim says "Execution not verified," the code has not been run. Treat it as untested. This document will never pretend untested code was executed.

Code examples frequently pair a *dangerous* version with a *corrected* version. Read the dangerous version to understand the failure mode, but never copy it into real code.

The Dependency Rule

The table of contents is a dependency graph. The concept dependency graph in architecture/CONCEPT_GRAPH.md makes the edges explicit:

c.ptr.basics -> c.types.ptr-type

means "pointer basics depend on pointer types; learn pointer types first."

If you hit a section and it does not make sense, the most common reason is that you skipped a prerequisite. Go back.

Do Not Skip the Projects

The curriculum includes twenty-five projects, from a calculator to a driver. They are not optional. Reading every chapter without building the projects produces recognition, not mastery. The projects are placed at the end, but each one lists the earlier chapters it exercises; you may do a project as soon as you have its prerequisites.

Verification and Accuracy

This document is written to be technically correct, and it tells you when a claim has been verified. It classifies technically significant claims as:

• VERIFIED
• PARTIALLY VERIFIED
• STANDARD-VERSION-DEPENDENT
• IMPLEMENTATION-DEFINED
• UNSPECIFIED
• PLATFORM-SPECIFIC
• COMPILER-SPECIFIC
• UNCERTAIN
• NEEDS EXTERNAL VERIFICATION

When subtle language-lawyer claims matter, the authority is the C standard, WG14 documents, and official compiler/POSIX/OS/hardware documentation — not forums or blogs.

What You Should Now Know

• The document is a dependency-ordered curriculum, not a reference dump.
• ISO C, the C standard library, POSIX, OS APIs, and hardware behavior are

distinct and kept separate.

• C17 is the baseline; version differences are explicit.
• Mastery is tracked in eight levels and is earned by doing, not reading.
• Badges have fixed meanings.
• Untested code is labeled as such; nothing is claimed to run unless it did.

Progress

• [ ] Read
• [ ] Understand
• [ ] Complete examples
• [ ] Complete exercises
• [ ] Complete deep challenge

Concept checkboxes

(No language concepts are introduced in this orientation chapter.)

Mastery levels

Verification

• The chapter structure, mastery levels, and badge meanings are defined by the

project architecture files in architecture/. VERIFIED (self-consistent with this repository's own specification).

• No code examples appear in this chapter, so no execution verification is

required.

Related Concepts

• Next: c.orientation.1 — The C Landscape.