I'm a recovering programmer who has been designing video games since the 1980s, doing things that seem baroquely hardcore in retrospect, like writing Super Nintendo games entirely in assembly language. These days I use whatever tools are the most fun and give me the biggest advantage.
james.hague @ gmail.com
Where are the comments?
How much memory does malloc(0) allocate?On most systems, this little C program will soak up all available memory:
malloc(0), let's look at the simpler case of
There's an interesting new C programmer question about
malloc: "Given a pointer to dynamically allocated memory, how can I determine how many bytes it points to?" The answer, rather frustratingly, is "you can't." But when you call
freeon that same pointer, the memory allocator knows how big the block is, so it's stored somewhere. That somewhere is commonly adjacent to the allocated memory, along with any other implementation-specific data needed for the allocator.
In the popular
dlmallocimplementation, between 4 and 16 bytes of this overhead are added to a request, depending on how the library is configured and whether pointers are 32 or 64 bits. 8 bytes is a reasonable guess for a 64-bit system.
To complicate matters, there's a minimum block size that can be returned by
malloc. Alignment is one reason. If there's an integer size secretly prepended to each block, then it doesn't make sense to allocate a block smaller than an integer. But there's another reason: when a block is freed, it gets tracked somehow. Maybe it goes into a linked list, maybe a tree, maybe something fancier. Regardless, the pointers or other data to make that work have to go somewhere, and inside the just-freed block is a natural choice.
dlmalloc, the smallest allowed allocation is 32 bytes on a 64-bit system. Going back to the
malloc(1)question, 8 bytes of overhead are added to our need for a single byte, and the total is smaller than the minimum of 32, so that's our answer:
malloc(1)allocates 32 bytes.
Now we can approach the case of allocating zero bytes. It turns out there's a silly debate about the right thing to do, and it hasn't been resolved, so technically allocating zero bytes is implementation-specific behavior. One side thinks that
malloc(0)should return a null pointer and be done with it. It works, if you don't mind a null return value serving double duty. It can either mean "out of memory" or "you didn't request any memory."
The more common scheme is that
malloc(0)returns a unique pointer. You shouldn't dereference that pointer because it's conceptually pointing to zero bytes, but we know from our adventures above that at least
dlmallocis always going to allocate a 32 byte block on a 64-bit system, so that's the final answer: it takes 32 bytes to fulfill your request for no memory.
[EDIT: I modified the last two paragraphs to correct errors pointed out in email and a discussion thread on reddit. Thank you for all the feedback!]
(If you liked this, you might enjoy Another Programming Idiom You've Never Heard Of.)