What's the point of malloc(0)?

Question

I just saw this code:

artist = (char *) malloc(0);

...and I was wondering why would one do this?

Answer 1

There are a lot of half true answers around here, so here are the hard facts. The man-page for malloc() says:

If size is 0, then malloc() returns either NULL, or a unique pointer value that can later be successfully passed to free().

That means, there is absolutely no guarantee that the result of malloc(0) is either unique or not NULL. The only guarantee is provided by the definition of free(), again, here is what the man-page says:

If ptr is NULL, no operation is performed.

So, whatever malloc(0) returns, it can safely be passed to free(). But so can a NULL pointer.

Consequently, writing artist = malloc(0); is in no way better than writing artist = NULL;

Answer 2

Admittedly, I have never seen this before, this is the first time I've seen this syntax, one could say, a classic case of function overkill. In conjunction to Reed's answer, I would like to point out that there is a similar thing, that appears like an overloaded function realloc:

• foo is non-NULL and size is zero, realloc(foo, size);. When you pass in a non-NULL pointer and size of zero to realloc, realloc behaves as if you’ve called free(…)
• foo is NULL and size is non-zero and greater than 1, realloc(foo, size);. When you pass in a NULL pointer and size is non-zero, realloc behaves as if you’ve called malloc(…)

Hope this helps, Best regards, Tom.

Answer 3

In Windows:

• void *p = malloc(0); will allocate a zero-length buffer on the local heap. The pointer returned is a valid heap pointer.
• malloc ultimately calls HeapAlloc using the default C runtime heap which then calls RtlAllocateHeap, etc.
• free(p); uses HeapFree to free the 0-length buffer on the heap. Not freeing it would result in a memory leak.

Answer 4

Why you shouldn't do this...

Since malloc's return value is implementation dependent, you may get a NULL pointer or some other address back. This can end up creating heap-buffer overflows if error handling code doesn't check both size and returned value, leading to stability issues (crashes) or even worse security issues.

Consider this example, where further accessing memory via returned address will corrupt heap iff size is zero and implementation returns a non NULL value back.

size_t size;

/* Initialize size, possibly by user-controlled input */

int *list = (int *)malloc(size);
if (list == NULL) {
  /* Handle allocation error */
}
else {
  /* Continue processing list */
}

See this Secure Coding page from CERT Coding Standards where I took the example above for further reading.

Answer 5

malloc(0) doesn't make any sense to me, unless the code is relying on behaviour specific to the implementation. If the code is meant to be portable, then it has to account for the fact that a NULL return from malloc(0) isn't a failure. So why not just assign NULL to artist anyway, since that's a valid successful result, and is less code, and won't cause your maintenance programmers to take time figuring it out?

malloc(SOME_CONSTANT_THAT_MIGHT_BE_ZERO) or malloc(some_variable_which_might_be_zero) perhaps could have their uses, although again you have to take extra care not to treat a NULL return as a failure if the value is 0, but a 0 size is supposed to be OK.