The Box and the Address

C was not designed as a general-purpose language that later turned out to be good for operating systems. It was designed to write one specific operating system, and turned out to be good at everything else.

Ritchie and Ken Thompson had written Unix in assembly language, which meant it only ran on the machine it was written for and had to be rewritten by hand for every new one. They wanted something portable enough to move between machines but close enough to the hardware that it could still be an operating system. C is the result, and that origin explains nearly every design decision in it — including the uncomfortable ones.

There is no runtime underneath it

This is the big one. When you run a Python script, the thing actually executing is the CPython interpreter — a large C program with a garbage collector, an object system and a bytecode loop. Something has to load and run that interpreter, and that something is the operating system. You cannot write the OS in Python, because Python needs the OS to already exist.

C compiles to a bare sequence of machine instructions that require essentially nothing beneath them. A C function can be the literal first thing that executes after the bootloader hands over control.

It maps closely to what the machine does

C's model of the world is: memory is one large flat array of bytes, variables are locations in it, and operations are things a CPU can do in a handful of instructions. People call it "portable assembly," which is glib but useful. When you write a + b you can predict roughly what instructions come out — and that predictability matters enormously when you are writing an interrupt handler with a hard deadline.

You manage memory yourself

An operating system is the thing that hands out memory. It cannot be sitting on top of an automatic memory manager; that is backwards. And garbage collection pauses are unacceptable in a kernel — you cannot tell a disk controller to hold on while you run a collection.

You can talk to hardware directly

A great deal of device control works by writing bytes to specific physical addresses, a technique called memory-mapped I/O. "Write 0x1 to address 0xB8000" is a single line of C and is not expressible in Python at all. C structures also have a defined byte layout, so you can lay a struct directly over a hardware register block or a network packet and read the fields by name.

Everything speaks C

The C calling convention — the ABI — is the lingua franca of computing. Python calls into C, Rust calls into C, your GPU driver exposes a C interface. Even languages designed specifically to replace C use its conventions to talk to the rest of the world.

Python runs your source file. C does not — it converts your source into a standalone executable file first, and then you run that. Those are two separate commands, and the gap between them is where most first-day confusion lives.

#include <stdio.h>

int main(void) {
    printf("Hello, world\n");
    return 0;
}

$ gcc -Wall -Wextra -g hello.c -o hello
  ↑    ↑            ↑         ↑
  |    |            |         └─ name the output file "hello"
  |    |            └─ keep debug information
  |    └─ turn on all the warnings
  └─ the compiler

$ ./hello
Hello, world

Line by line

• #include <stdio.h> — this is a preprocessor directive, not an import. Before compiling, a separate pass literally pastes the entire contents of stdio.h into your file. That header declares what printf looks like so the compiler knows how to call it.
• int main(void) — every C program starts at main. It returns an int, which becomes the process's exit code. void in the parameter list means "takes no arguments."
• \n — there is no automatic newline. printf prints exactly the characters you give it and nothing more. That \n is the byte 0x0a.
• return 0 — zero means success. Every shell and script in existence depends on this convention.

What actually happens to your file

"Compiling" is four separate programs run in sequence. You almost never see the middle steps, but knowing they exist turns a whole category of baffling error messages into obvious ones.

$ gcc -E hello.c -o hello.i     # stop after preprocessing

hello.c   :   6 lines
hello.i   : 819 lines   ← stdio.h has been pasted in

# somewhere in those 819 lines, the thing you needed:
extern int printf (const char *__restrict __format, ...);

$ gcc -S -masm=intel hello.c -o hello.s   # emit assembly, readable syntax
#
# -masm=intel is doing real work here. gcc defaults to AT&T
# syntax, which writes the same instruction as:
#     leaq  .LC0(%rip), %rax
# Same machine code, different notation — operands reversed
# and decorated with % and $. Intel syntax is what Intel's
# own manuals use, so it is the one worth reading first.

main:
        endbr64
        push    rbp
        mov     rbp, rsp
        lea     rax, .LC0[rip]      # address of "Hello, world"
        mov     rdi, rax            # put it in the first argument register
        call    puts@PLT            # ← wait, that says puts, not printf
        mov     eax, 0              # return 0
        pop     rbp
        ret

$ gcc -c hello.c -o hello.o     # assemble into machine code

# hello.o now contains real x86-64 instructions, but it is
# NOT runnable. It has a hole in it where puts should be:

$ nm hello.o
0000000000000000 T main              ← defined here
                 U puts              ← U = Undefined. Someone else must supply it.

$ gcc hello.o -o hello           # link

$ ldd hello
    linux-vdso.so.1
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6   ← puts lives here
    /lib64/ld-linux-x86-64.so.2

$ ls -l hello
17000 bytes   # for a five-line program

In Python a variable is a name loosely attached to an object of whatever kind. In C, every variable has a type you declare, and that type decides exactly how many bytes it occupies — permanently, before the program ever runs.

#include <stdio.h>

int main(void) {
    int    count  = 42;
    char   letter = 'A';
    double ratio  = 0.5;

    printf("%d %c %f\n", count, letter, ratio);
    return 0;
}

printf trusts you completely

Those %d, %c and %f markers are format specifiers, and here is your first real taste of C's philosophy: printf has no idea what you actually passed it. It reads the format string, sees %d, and goes to fetch an integer — whether or not you gave it one. If you were wrong, it fetches whatever happens to be lying around.

Before pointers make any sense, you need C's picture of memory — and it is much simpler than you might expect.

Memory is one enormous row of byte-sized boxes, numbered from zero upwards. That number is the byte's address. Nothing else is going on. There are no objects, no names, no structure — the structure is entirely in your program's head. A variable is nothing more than an agreement between you and the compiler that a particular stretch of those boxes, starting at a particular address, is to be treated as an int.

long long v = 42;
void *addr = &v;

printf("%p", addr);            → 0x7fff19ffc870
printf("%lld", *(long long *)addr); → 42

// now read the very same bytes one at a time:
unsigned char *b = (unsigned char *)addr;
for (int i = 0; i < 8; i++) printf("%02x ", b[i]);

→ 2a 00 00 00 00 00 00 00

A pointer is a variable whose value is an address. That is the entire definition. Everything difficult about it is notation, not concept.

Three pieces of syntax do all the work, and they are genuinely confusing at first because the * symbol means two different things depending on where it appears:

Step through the program below one line at a time and watch memory change. The addresses are real — captured from an actual run on this machine.

Write a function that swaps two integers. Try it the obvious way first and watch it silently do nothing — that failure teaches the rule better than any explanation.

When you call a function in C, every argument is copied into the function's own variables. The function gets its own private boxes. It can scribble in them all it likes, and the caller's originals are untouched, because they were never involved. There is no exception to this rule — which means the only way to let a function modify your variable is to hand it the address and let it reach back.

C has no string type. A "string" is an array of char with a zero byte on the end, and that single decision is the ancestor of an enormous share of the security bugs in computing history.

A char is one byte and is genuinely just a small integer — 'A' is 65, and you can do arithmetic on it. To know where a string stops, C does not store a length. It puts a zero byte at the end and every string function scans forward until it hits one.

char s[] = "Hello";

printf("strlen(s) = %zu\n", strlen(s));  → 5
printf("sizeof(s) = %zu\n", sizeof(s));  → 6   ← one more

  s[0] =  72  0x48  'H'
  s[1] = 101  0x65  'e'
  s[2] = 108  0x6c  'l'
  s[3] = 108  0x6c  'l'
  s[4] = 111  0x6f  'o'
  s[5] =   0  0x00  the terminator

A struct groups several values into one thing and — crucially — guarantees where each one sits. Once you can read a struct, you can read the source of nearly everything.

This matters more in C than the equivalent does elsewhere, because a struct is not an object with hidden internals. It is a map of byte offsets. If you know a struct's definition and you have its address, you can compute exactly where any field lives and read it.

Which is what you were doing, in Python, several pages ago. Here is the actual layout of a CPython integer, declared in C and compiled to confirm the offsets. Click any field.

One wrinkle: padding

The struct above is 28 bytes of actual fields but sizeof reports 32. The compiler inserts unused bytes so each field starts at an address that is a multiple of its own size — CPUs read aligned data considerably faster, and some refuse unaligned reads outright. The consequence is that field order changes how much memory your struct uses:

Same three fields, same data, 50% more memory — purely from the order they were declared. In a kernel structure allocated millions of times, that is a real number, and it is why you will see kernel structs written largest-field-first.

The order to learn things in

1. Pointers — you have started. Keep going until & and * read as words rather than punctuation.
2. Arrays, and how they decay into pointers — an array's name silently becomes the address of its first element in almost every context. This surprises everyone once.
3. Strings and the standard string functions — strlen, strcpy, strcmp, and why the safer variants exist.
4. Structs — section 09 was an introduction; there is more, particularly pointers to structs and the -> operator.
5. malloc and free — asking the OS for memory and giving it back. This is where C gets genuinely dangerous and genuinely powerful.
6. Header files and multi-file compilation — how real programs are organised.

Somewhere in there, learn what the linker actually does. Section 03 gave you the outline; without it, "undefined reference to..." is a mystery people fight for weeks.

Resources

• Beej's Guide to C Programming — free online, modern, and genuinely pleasant to read. The best starting point.
• K&R (Kernighan & Ritchie, The C Programming Language) — the canonical book, co-written by the man who made the language. Short, dense, dated in places, still worth it.
• Operating Systems: Three Easy Pieces — free, excellent, and the right book if OS internals are the actual motivation. It teaches OS concepts with C throughout.
• xv6 — MIT's teaching operating system. A complete Unix-like kernel in about 6,000 lines of readable C. Once pointers and structs are comfortable, reading it is the fastest way to see how the pieces fit.