July 23, 2026
13 bytes, infinite drama
Why malloc always does more than I asked for?
You asked for 13 bytes, but memory sneaks in extras and the comments are loving the chaos
TLDR: The article explains that asking for a small chunk of memory often comes with hidden extra space so the system can track and safely reuse it later. Commenters loved the clear teaching, but immediately argued over wasted space, missing details, and one possible bug — peak internet engineer behavior.
A seemingly innocent question — why asking a computer for 13 tiny bits of memory usually gets you more than 13 — turned into the kind of nerdy soap opera the internet lives for. The post walks readers through the big reveal: when a program asks for memory, it often gets extra hidden space so the computer can keep track of it later and place it neatly where the machine likes it. In plain English, your order of 13 comes with surprise packaging, labels, and bubble wrap.
But the real fireworks were in the comments. One camp was genuinely impressed, with readers praising the article’s line that memory managers need to remember what they handed out if they ever want to take it back. Another camp immediately kicked the tires. One commenter swooped in with a classic correction: memory allocation doesn’t know what kind of data you’ll store, so it has to play it safe and return something broadly usable. Then came the efficiency warriors, grumbling that the article’s extra “back pointer” felt like paying for deluxe shipping when standard packaging would do.
And of course, because this is the internet, someone found a possible bug almost instantly, warning that one innocent-looking line could turn into a disaster if the numbers get too big. That mix of teacher’s-pet praise, pedantic nitpicking, and ‘gotcha’ energy is exactly why this discussion popped off. The vibe? Equal parts classroom, courtroom, and roast session.
Key Points
- •The article states that `malloc(13)` typically reserves more memory internally than the 13 bytes requested by the caller.
- •A bump allocator is presented as the simplest allocator design, advancing a cursor through a preallocated arena without supporting individual frees.
- •The article explains that `free(ptr)` needs allocator metadata because it receives only a pointer and must recover allocation size and boundaries.
- •A naive allocator can store a size header directly before user memory, allowing `free()` to walk backward from the returned pointer.
- •Alignment requirements can force variable padding between metadata and user memory, making a fixed backward step to locate the header unreliable.