How much memory does malloc(0) allocate?

原文：http://prog21.dadgum.com/179.html

On most systems, this little C program will soak up all available memory:

while (1) {
   malloc(0);
}

so the answer is not the obvious "zero." But before getting into malloc(0), let's look at the simpler case of malloc(1).

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 free on 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 dlmalloc implementation, 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.

In 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 dlmalloc is 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.)