Scrolls
6 min read
On this page

The C Mental Model

C is a thin layer over assembly language. To write C well, you need a mental model of what the machine is actually doing. Every other language hides the machine behind abstractions. C does not. This is simultaneously the source of C's power and its danger.

Everything is Memory

The fundamental insight of C is that everything in your program is memory. Variables, arrays, structs, function pointers, strings — all of them are regions of bytes at specific addresses.

Variables Are Named Memory Locations

When you write int x = 42;, the compiler allocates 4 bytes (on most platforms) and stores the value 42 in those bytes. The name x is a compile-time convenience — it does not exist at runtime. The compiled code just reads and writes to a specific memory address.

#include <stdio.h>

int main(void) {
    int x = 42;
    int y = 100;

    printf("x is at address %p, value %d\n", (void *)&x, x);
    printf("y is at address %p, value %d\n", (void *)&y, y);
    printf("Distance: %td bytes\n", (char *)&x - (char *)&y);

    return 0;
}

x is at address 0x7ffd2a3b4c58, value 42
y is at address 0x7ffd2a3b4c54, value 100
Distance: 4 bytes

The variables are adjacent in memory. They are just bytes on the stack.

Pointers Are Memory Addresses

A pointer is a variable whose value is a memory address. That is the entire concept. There is no magic, no indirection layer, no reference counting. A pointer is a number that happens to represent a location in memory.

#include <stdio.h>

int main(void) {
    int x = 42;
    int *p = &x;    // p holds the address of x

    printf("p holds address: %p\n", (void *)p);
    printf("value at that address: %d\n", *p);

    *p = 99;        // write 99 to the address p holds
    printf("x is now: %d\n", x);

    return 0;
}

p holds address: 0x7ffd2a3b4c58
value at that address: 42
x is now: 99

Arrays Are Contiguous Memory

An array is a block of adjacent memory locations of the same type. int arr[5] allocates 20 contiguous bytes (5 integers, 4 bytes each). There is no array object, no length field, no bounds metadata. Just bytes in a row.

#include <stdio.h>

int main(void) {
    int arr[5] = {10, 20, 30, 40, 50};

    for (int i = 0; i < 5; i++) {
        printf("arr[%d] at %p = %d\n", i, (void *)&arr[i], arr[i]);
    }

    return 0;
}

arr[0] at 0x7ffd2a3b4c40 = 10
arr[1] at 0x7ffd2a3b4c44 = 20
arr[2] at 0x7ffd2a3b4c48 = 30
arr[3] at 0x7ffd2a3b4c4c = 40
arr[4] at 0x7ffd2a3b4c50 = 50

Each element is exactly 4 bytes after the previous one. arr[3] means "start at the base address of arr, move forward 3 * sizeof(int) bytes, and read the integer there."

The Stack & The Heap

C gives you two regions of memory to work with, and understanding the difference is essential.

The Stack

Local variables live on the stack. The stack is a fixed-size region of memory (typically 1-8 MB) that grows and shrinks automatically as functions are called and return.

void foo(void) {
    int local = 42;     // allocated on the stack when foo is called
    // ... use local ...
}                        // local is deallocated when foo returns

Stack allocation is nearly free — the compiler just adjusts the stack pointer. But stack memory is limited and temporary. You cannot return a pointer to a local variable because that memory is reclaimed when the function returns.

The Heap

Heap memory is allocated explicitly with malloc and freed explicitly with free. The heap is large (limited only by available system memory) and persistent (it stays allocated until you free it).

#include <stdlib.h>
#include <stdio.h>

int main(void) {
    int *p = malloc(sizeof(int) * 100);  // allocate 100 ints on the heap
    if (p == NULL) {
        fprintf(stderr, "allocation failed\n");
        return 1;
    }

    p[0] = 42;
    printf("p[0] = %d\n", p[0]);

    free(p);   // you must free heap memory yourself
    return 0;
}

The trade-off: stack allocation is fast but limited and automatic. Heap allocation is flexible but requires manual management and is slower.

There Is No Safety Net

C trusts you. It assumes you know what you are doing. When you violate that trust, the result is not a helpful error message — it is a crash, corrupted data, or a security vulnerability.

No Bounds Checking

int arr[5] = {1, 2, 3, 4, 5};
arr[10] = 999;   // no error, no exception — writes to memory you don't own

In Python, this raises an IndexError. In Java, an ArrayIndexOutOfBoundsException. In C, this silently writes to whatever memory happens to be 10 integers past the start of arr. It might overwrite another variable. It might overwrite a return address on the stack. It might crash. It might appear to work perfectly and then fail catastrophically in production.

No Garbage Collector

void leak_memory(void) {
    int *p = malloc(1024);
    // forgot to call free(p)
}   // p goes out of scope, but the 1024 bytes are still allocated
    // they are now unreachable — a memory leak

Every byte you allocate with malloc must eventually be freed with free. If you forget, the memory is leaked. If your program runs long enough, it runs out of memory. C will not clean up after you.

No Exceptions

FILE *f = fopen("data.txt", "r");
// f might be NULL if the file doesn't exist
// C does not throw an exception — you must check
if (f == NULL) {
    perror("fopen");
    return 1;
}

Every function that can fail returns an error indicator. It is your responsibility to check it. C does not have try/catch. Error handling is explicit and manual.

Undefined Behavior

Undefined behavior (UB) is the most important concept in C. When your program has undefined behavior, the C standard says literally anything can happen. The compiler is free to assume that undefined behavior never occurs, and it optimizes accordingly.

Examples of Undefined Behavior

// Signed integer overflow
int x = INT_MAX;
x = x + 1;           // undefined behavior

// Null pointer dereference
int *p = NULL;
int y = *p;           // undefined behavior

// Using a variable before initialization
int z;
printf("%d\n", z);    // undefined behavior

// Accessing freed memory
int *q = malloc(sizeof(int));
free(q);
*q = 42;              // undefined behavior

Why UB is Dangerous

The compiler assumes UB does not happen. This means it can optimize based on that assumption.

int check_overflow(int x) {
    if (x + 1 > x) {
        return 1;   // "of course x + 1 > x"
    }
    return 0;
}

A reasonable programmer might expect this to return 0 when x is INT_MAX (because INT_MAX + 1 wraps around). But signed overflow is UB, so the compiler assumes it never happens. The compiler can legally optimize this function to always return 1. And it will, at -O2 or higher.

The Compiler Is Not Your Enemy

Undefined behavior exists because it allows the compiler to generate faster code. If the compiler had to check for overflow on every addition, C would be much slower. The contract is: you write correct code, the compiler makes it fast. Break the contract, and the compiler's optimizations turn into bugs.

Types Are Interpretation, Not Reality

In C, types tell the compiler how to interpret a region of memory. The memory itself is just bytes.

#include <stdio.h>

int main(void) {
    int x = 1078530011;
    float *fp = (float *)&x;

    printf("As int: %d\n", x);
    printf("As float: %f\n", *fp);

    return 0;
}

As int: 1078530011
As float: 3.140000

The same four bytes, interpreted as an integer, give you 1078530011. Interpreted as a float, they give you approximately pi. The bytes did not change — only the interpretation did. (Note: this particular technique violates strict aliasing rules; in practice, use memcpy for type punning.)

The Power & The Danger

C gives you direct access to memory, precise control over data layout, and zero overhead abstractions. These properties make C the right choice for operating systems, databases, and embedded systems.

But these same properties mean that C does not prevent you from:

  • Reading memory you do not own
  • Writing past the end of a buffer
  • Using memory after freeing it
  • Interpreting bytes as the wrong type
  • Ignoring error conditions

Every other modern language exists, in part, to prevent these mistakes. C chooses performance and control over safety. That is not a flaw — it is a design decision. The question is whether you understand the trade-off.

Common Pitfalls

  • Assuming C behaves like Java or Python — C has no objects, no exceptions, no garbage collector, no bounds checking. Bringing high-level assumptions to C produces dangerous code.
  • Ignoring undefined behavior — "it works on my machine" is not a valid argument in C. Code with UB might work today and break when you change compilers, optimization levels, or target architectures.
  • Thinking the compiler is optional — in C, the compiler is your most important tool. It catches bugs through warnings, optimizes through UB assumptions, and generates the machine code you will actually run. Understand what it does.
  • Treating memory as infinite — stack space is limited. Heap allocations can fail. Every allocation has a cost. C makes you think about memory because the machine has to.

Key Takeaways

  • C is a thin abstraction over hardware. Variables are memory locations, pointers are addresses, arrays are contiguous bytes.
  • The stack is fast and automatic but limited. The heap is flexible but requires manual management.
  • C has no safety net: no bounds checking, no garbage collector, no exceptions. You are responsible for correctness.
  • Undefined behavior is a contract: write correct code, and the compiler makes it fast. Write incorrect code, and the compiler makes it worse.
  • Types in C are interpretation rules applied to raw bytes in memory.
  • Understanding this mental model is the prerequisite for writing correct C. Every bug in C — buffer overflows, use-after-free, memory leaks — traces back to violating one of these fundamentals.