Low-level C programming, systems concepts, and the occasional rabbit hole. Posts on allocators, data structures, OOP patterns in C, and a growing language called Zinc.
Type Erasure: Generic Arrays with void* and memcpy
Post 4 of the Dynamic Arrays in C series · Full source code on GitHub The Limitation We’ve Been Ignoring For three posts, our array has stored integers. Only integers. If you wanted to store floats, you’d write a FloatArray, same struct, same logic, same push function, just with float instead of int everywhere. If you wanted to store a 20-byte struct, you’d write a StructArray. And another for double. And another for char*. Every new type means a new copy of the same code with the same bugs, the same growth logic, the same visualization, the same tests, just with a different type name. ...
The Growth Factor Debate: 1.5x, 2x, or Something Else?
Post 3 of the Dynamic Arrays in C series · Full source code on GitHub The Choice We Skipped In Post 2, we solved the “array is full” problem by doubling the capacity on every realloc. We wrote new_cap = old_cap * 2, watched the buffer grow from 2 to 4 to 8 to 16, and moved on. Three reallocations for 12 elementsm, pretty good. But we never justified the number 2. Why not 1.5? Why not 3? Why not just add 100 slots every time? ...
Growing Pains: realloc and Automatic Capacity Management
Post 2 of the Dynamic Arrays in C series · Full source code Where We Left Off In Post 1 we built an array that does three things: allocate a fixed buffer, push integers into it, and free everything when we’re done. It works, until it doesn’t. The moment the user pushes one element more than the initial capacity allows, array_push returns -1 and refuses to cooperate. The array is full and there’s nothing we can do about it. ...
My Terminal Setup: Neovim 0.12, tmux, and Going Native
Every developer has opinions about their editor. Most of those opinions are wrong. Mine are also probably wrong, but at least I understand every line in my config. This post walks through the terminal setup I use for C development, note-taking, and everything in between. The dotfiles are on Codeberg if you want to skip the words and read the code. But if you’re curious about why things are the way they are, why I don’t use Mason, why there’s no nvim-cmp, why my shell config is 130 lines instead of a framework, keep reading. ...
Hello, Array: malloc, free and Manual Bookkeeping
Post 1 of the Dynamic Arrays in C series · Full source code The Problem No One Starts With You have five integers. You put them in an array: 1 int numbers[5] = {10, 20, 30, 40, 50}; Done. C gives you a contiguous chunk of 20 bytes on the stack, indexed from 0 to 4, and life is good. Now your user wants to add a sixth integer. What do you do? You can’t resize a stack array. Its size was baked into the binary at compile time, the compiler saw 5, calculated 20 bytes, and that’s the space your function’s stack frame has. There’s no negotiation. You could declare int numbers[1000] and hope it’s big enough, but hope is not a memory management strategy. ...
What malloc() does not want you to know
Post 1 of 13 — Series: Memory Allocation and Garbage Collection from Scratch Every time you write malloc(128), something apparently magical happens: the runtime hands you a pointer to 128 bytes of memory nobody else is using. You didn’t ask the operating system for permission. You didn’t specify where those bytes should live. They simply appeared. And when you call free(), they vanish back into the void. The magic is a lie. ...
Hello World: Pointers, Memory, and Low-Level C
Every C project starts with a printf("Hello, World!\n");, and this blog is no exception. Welcome to pablogs.dev. I’ve been wanting to create a personal space for a while now to document my projects, organize my thoughts, and most importantly, share what I learn about systems programming and low-level C. Often, when coding in higher-level languages, we take the underlying magic for granted: how memory is allocated, how resources are cleaned up, or how data structures grow. ...