Why malloc always does more than I asked for?

Post by [deleted] » Thu, Jul 23, 2026, 11:39 AM UTC

Someone wrote: post #40

inigyou wrote: post #36

Earlier quoted context omitted.

I suppose by default it will just call free, but you can substitute different malloc implementations, maybe one with a malloc_no_header function

Because free still exists and there is no “allocate this number of bytes of memory; I promise to free it with a call to free_size ” call, you can’t have a malloc implementation that doesn’t track block sizes. I think the only thing free_size adds is robustness. Allocators can check the passed in size with what they know and abort the program if they do not match. That can thwart some security issues.

Post by AndrewStephens » Thu, Jul 23, 2026, 12:10 PM UTC

inigyou wrote: post #34

pjmlp wrote: post #21

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.

These still exist, like dlmalloc, jemalloc, tmalloc (which has new features). Built-in malloc is good enough for almost everything if you don't have excessive time on your hands, but thinking deeper about memory allocation is one of those things that can make your software higher quality if you have time for it—just like utilising SIMD (also on today's front page) or careful use of caching.

Post by badsectoracula » Thu, Jul 23, 2026, 12:19 PM UTC

magicalhippo wrote: post #38

phire wrote: post #8

> 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 val…

> So all malloc implementations have a minimum alignment guarantee. Typically 16 bytes these days on x86 Fun story. Back in the early 2000s, my Delphi OpenGL program randomly crashed when I tried to use vertex buffers. I spent a lot of time checking this and that, before I realized it might be an alignment issue. Sure enough, Delphi memory allocator at the time only provided 4-byte alignment, while NVIDIA's drivers u…

Post by nathaah3 » Thu, Jul 23, 2026, 12:23 PM UTC

CodesInChaos wrote: post #12

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 I'd rewrite it like this: if (size > a->limit - a->cursor) return NULL; // out of memory

Post by magicalhippo » Thu, Jul 23, 2026, 12:41 PM UTC

badsectoracula wrote: post #45

magicalhippo wrote: post #38

Earlier quoted context omitted.

> So all malloc implementations have a minimum alignment guarantee. Typically 16 bytes these days on x86 Fun story. Back in the early 2000s, my Delphi OpenGL program randomly crashed when I tried to use vertex buffers. I spent a lot of time checking this and that, before I realized it might be an alignment issue. Sure enough, Delphi memory allocator at the time only provided 4-byte alignment, while NVIDIA's drivers u…

IMO that sounds either like a bug in Nvidia's drivers (IIRC OpenGL doesn't require that sort of alignment) or -more likely- your code having some other memory related-bug (e.g. accessing data out of bounds) that the extra bytes you got from alignment masked it.