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. ...

June 3, 2026 · 15 min · pablo

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? ...

June 1, 2026 · 17 min · pablo

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. ...

May 24, 2026 · 18 min · pablo