Roadmap to C

This post is for you if you

• are comfortable programming;
• do not know C;
• have some notion, for whatever reason, that you should learn C.

It's also a companion post to Roadmap to game engine dev.

Why should I not learn C?

Because Rust exists.

Why should I learn C?

So you can appreciate why Rust does what it does.

Because C is the skeleton key that matches all locks. Because you can - in a very broad sense, stronger than is true for other languages - do anything in C.

Because you want to!

How did you (the writer) learn C?

The C Programming Language by Kernighan and Ritchie (henceforth "K&R") sucks. I mean, no, it's perfect and comprehensive and it gives you everything you need, without dumbing anything down. But it was written in 1988 for a very different audience, pre-internet era, which means it has quirks. The code itself is atrocious, for one. And the kind of programs they write and suggest you write are mind-numbingly boring. K&R are systems programmers who write programs to write programs to write programs. There is no semblance of play, no hint of the real world shining through in here. K&R is one part honest didactic tool, one part cold, hard reference monolith.

I did not learn C by reading K&R. I read K&R after I'd already basically understood the key concepts and implemented some small projects, like LZW compression/decompression; a custom drop-in malloc library; and socket-based networking. That was in a managed course/bootcamp thingy, with mentors and peers, partly following Harvard's CS50x https://www.edx.org/learn/computer-science/harvard-university-cs50-s-introduction-to-computer-science.

I approached this from a very basic level of programming competency: C is, basically, my native tongue. However, for someone with greater experience in programming, who's confident with a memory-managed language (Python, C#, JavaScript, anything really), who's ready to search and self-teach, I propose a different roadmap.

How should I (the reader) learn C?

Get a copy of K&R. You can find it on the first page of any respectable search engine. Just make double sure it's the Second Edition - "ANSI C!", it exclaims with pride, eager to show you the future of programming.

Go through the roadmap below until you find something you don't understand. Then open up K&R and read up to where it's explained, and/or search the internet, and/or ask a friend or mentor.

That last thing is important. If at all possible, don't do this alone. It's really boring and discouraging on your own. (If you're a normal person, learning C is boring and discouraging even with friends, but at least this way you can suffer together.)

Do some of K&R's exercises when you see them, but not the really annoying or boring ones. Don't drain your soul - just make sure you're actually absorbing the prerequisites as they come up, so that you develop a mental map of the language.

The items are very roughly ordered. Consider them also as a to-do list. You might need to jump forwards and back on occasion, and should always keep the whole in mind. Each group of bullet points is reinforced and/or taught by the project below it.

The roadmap

Start!

• Basic syntax.
• Understand that C gives you no affordances in string manipulation. Null-terminated strings, all ASCII-encoded, and definitely not dynamically growable.
• The wonky format of printf() (be able to look it up).
• How to compile a program.

PROJECT: Hello World. Read name on command-line input and print it back out. And... compile the program. K&R - incredibly - does not teach you this at all. It was written in the days when a "compiler" was a boxful of 3.5" discs that you mail-ordered or borrowed from your university faculty, and there were 20 different compilers that all sucked in different ways, and they all had completely different interfaces - so it didn't make sense to write about them in a book about the C language. Luckily, today, we have GCC and Clang (and, in a pinch, MSVC). Figure out which is appropriate for you.

• Declaring arrays.

PROJECT: make a program that calculates the first N prime numbers using trial division. Hard-code N using a #define. Compile with different optimisation levels. Measure how long they all take to run.

• Be comfortable with malloc()/free()/realloc() memory management. Sing it with me: "one malloc = one free"!
• So what is an array anyway? When do you declare a char * and when do you declare a char[]? How do you pass one to a function? "Arrays and pointers are basically the same thing, except they're not".

PROJECT: update your prime-calculator to not #define n but instead const int n = .... Now you'll need to use malloc(), where you didn't before - why? That's annoying, but conversely, what problems were there with the #define before?

• Comfortably dereference *pointers and pass around addresses of &values. Know when you'd need to do that. Know when you can't do that on pain of causing a memory leak or dangling pointer.
• Defining structs.
• File I/O.
• By now, you'll want to have an approximate idea of what the standard libraries look like (it's not much!). Be comfortable reading cppreference https://en.cppreference.com/w/c/io/fopen.html.

PROJECT: implement dynamically growable strings. Make a memo program that listens to what you type in on the command-line, concatenates it all together, and, when given a specific command, either prints it or writes it to a file. (Or something more interesting that you think of.)

• Defining recursive structs.

PROJECT: implement linked lists. Then implement trees. Use either or both of these for a program which walks a directory and all subdirectories, remembering the name + size + etc. of each file; then prints them all out in a simple (horizontally-indented) tree structure. Basically, make ls to your personal taste.

• Bit manipulation. (This is the fun part! This might be the whole reason you wanted to get into C.)
• A bit more of the preprocessor: #ifdef and friends.

PROJECT: implement LZW compression/decompression. Add debug printing, but only print it when DEBUG is defined to the preprocessor. Compile with/without DEBUG, without changing source code.

• Know how to declare a variable whose type is "function taking a pointer-to-char and int, and returning pointer-to-char" - not necessarily off the top of your head (I can't), but know what the hell that means and where to look to remind yourself how to put it together.
• Variadic functions.
• You're now more or less done with K&R. There's more of the book to go, but to be honest, you've seen the juicy stuff - and you've hit the limits of its "ANSI C" (aka C89) date.

PROJECT: write your own printf(), using fputc(). Doing this exhaustively is really annoying. Just do the fun parts, and, y'know, the format of regular printf() sucks, so make up your own! (Bonus: support UTF-8 strings. Start here: https://www.joelonsoftware.com/2003/10/08/the-absolute-minimum-every-software-developer-absolutely-positively-must-know-about-unicode-and-character-sets-no-excuses/)

• Buffer overflow security. Repeat after me: "I will always use snprintf() and never regular printf(), except ..." - when? Why?
• What in god's name is vsnprintf_s() (what's the v, what's the s, what's the n, what's the second s...)??

PROJECT: you're now ready to follow the C half of Crafting Interpreters https://craftinginterpreters.com/! Read this and discover your inner compiler writer. The first half walks through a biggish project in Java. Follow along and redouble your appreciation for how much more convenient higher-level languages are - no Java experience needed. The second half does the same thing but different, in C, giving you a sense for building a big project and reinforcing everything learned so far. Just don't get too absorbed and forget to come back here!

PROJECT: implement malloc() and free(), using brk() or sbrk() or HeapAlloc() or GlobalAlloc() (why do those functions not appear on cppreference?). Use any algorithm you feel like - as dumb as you want, or go wild and do some research.

• Be comfortable with the three main steps of compilation (preprocessing -> compiling -> linking).
• Using a debugger.

PROJECT: create a library with your malloc()/free(). Make one of your earlier programs use your malloc()/free(), without changing their source code, by compiling with specific link order (and possibly include path). Now, you'd like to verify it worked and used your implementation, not built-in, by adding printf() statements... but you can't (why?). Instead, verify it by compiling with debug symbols and attaching a debugger (either gdb or the one built into your IDE... or both).

• The C ecosystem is a thousand boxes of mutually incompatible, very sharp, LEGO bricks. They don't come in any standardised box size, so you'll have to scoop them up by hand and arrange them on your workbench so they don't fall off. Sometimes, you can build your castle on top of their base. At other times, all you can do is bind them together with blu-tack and string.

PROJECT: make a graphical game, in a window, with a square that moves around (with WASD/arrow keys) and picks up coins that randomly spawn. Do this with either SDL3 or GLFW. Evaluate both libraries and pick the one you vibe with best. Do not use OpenGL at this time - just use your library's built-in rectangle-drawing functions. Don't worry about displaying your score (that's pretty tedious). (Bonus: link your game dynamically.) (Bonus: compile GLFW/SDL3 from source.)

PROJECT: figure out what the hell an "OpenGL loading library" is and why it should exist. Use glad https://github.com/Dav1dde/glad and GLFW (not SDL3, this time) to draw the classic "hello triangle" in beautiful RGB. (This is, approximately, the path to https://learnopengl.com/Getting-started/Hello-Triangle - follow that webpage if you like.)

You now know everything. Congratulations.