Why malloc always does more than I asked for?

> so alloc() doesn’t just need to hand back a pointer. it needs to hand back a pointer that’s correctly aligned for whatever type the caller is about to store there.

Malloc doesn't know the required alignment (because has no idea what the type is, everything is cast through void). So all malloc implementations have a minimum alignment guarantee. Typically 16 bytes these days on x86, as that means even 128bit SSE values will end up aligned by default.

You couldn't go below the sizeof(void ) anyway, the backpointer needs to aligned too.

The padding only happens when you use memalign or aligned_malloc to specify a much larger alignment.

Your bump allocator suffers from integer overflows turned into buffer overflows when the requested allocation is big enough:

  if (a->cursor + size > a->limit) return NULL; // out of memory

  if (size > a->limit - a->cursor) return NULL; // out of memory

I'm a little confused. We start with

  [ Header ][ ...variable padding... ][ Back Pointer ][ User Memory ]
                                       ^ always exactly sizeof(void*)
                                         bytes before User Memory,
                                         no matter how much padding
                                         came before it

  [ Header ][ Back Pointer ][ Padding ][ User Memory ]

Why bother with dynamic padding and a back pointer? That wastes at least 8 bytes.

You might as well always align to 8 bytes and make your header a multiple of 8.

Old magazines like The C/C++ Users' Journal and DDJ used to have ads for companies selling malloc()/free() replacement libraries, exactly because a single implementation isn't adequate to all scenarios.

I wrote this bump malloc that I use for very short lived Wasm modules: https://github.com/ncruces/wasm2go/blob/main/libc-gen/c/mall...

What if I want to allocate only 4 bits?

I bet this is better optimized in Rust.

Having to recode malloc and free from "scratch" in school was a great teaching experience and there's not a month since where I don't encounter something that I understand better thanks to that exercise.

I've read some allocator walkthroughs before but I thought that this line stood out:

"to get individual free() working, the allocator needs to remember something about every allocation it handed out. and that’s the moment metadata stops being optional."

That's just a very nice distillation of an important concept.