What's the point of malloc(0)?

The C standard (C17 7.22.3/1) says:

If the size of the space requested is zero, the behavior is implementation defined: either a null pointer is returned, or the behavior is as if the size were some nonzero value, except that the returned pointer shall not be used to access an object.

So, malloc(0) could return NULL or a valid pointer that may not be dereferenced. In either case, it's perfectly valid to call free() on it.

I don't really think malloc(0) has much use, except in cases when malloc(n) is called in a loop for example, and n might be zero.

Looking at the code in the link, I believe that the author had two misconceptions:

• malloc(0) returns a valid pointer always, and
• free(0) is bad.

So, he made sure that artist and other variables always had some "valid" value in them. The comment says as much: // these must always point at malloc'd data.

malloc(0) behaviour is implementation specific. The library can return NULL or have the regular malloc behaviour, with no memory allocated. Whatever it does, it must be documented somewhere.

Usually, it returns a pointer that is valid and unique but should NOT be dereferenced. Also note that it CAN consume memory even though it did not actually allocate anything.

It is possible to realloc a non null malloc(0) pointer.

Having a malloc(0) verbatim is not much use though. It's mostly used when a dynamic allocation is zero byte and you didn't care to validate it.

There's an answer elsewhere on this page that begins "malloc(0) will return a valid memory address and whose range will depend on the type of pointer which is being allocated memory". This statement is incorrect (I don't have enough reputation to comment on that answer directly, so can't put this comment directly under there).

Doing malloc(0) will not automatically allocate memory of correct size. The malloc function is unaware of what you're casting its result to. The malloc function relies purely on the size number that you give as its argument. You need to do malloc(sizeof(int)) to get enough storage to hold an int, for example, not 0.

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;

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.

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.

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.

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.

The person who wrote the code likely wants you to think of malloc(0) as an empty initialized array to which values are to be added (realloc()). While this works regardless of whether malloc(0) returns NULL or an actual pointer, it spawns ground for misunderstanding:

Without implementation-awareness, you won't be able to tell what a potential NULL returned by malloc(0) means. It could mean that you are out of memory, but it could also mean that that's what the implementation decides to return for allocations of size 0. Even if this is inconsequential to what your code does, it can raise some eyebrows.

This means that malloc(0) is an attempt at writing more readable code. However, due the fact that it engages implementation-specific behavior, losing information in the process, it is likely to cause confusion instead. Do not use it unless you specifically require the result of the implementation-specific behavior.

To actually answer the question made: there is no reason to do that

There are some benefits to get a valid pointer from malloc(0):

1. To separate malloc(0) from malloc(request too much memory), which actually return NULL.
2. If malloc(0) is valid pointer, that obligate you to call free for it. There is the scenario when you forget to call free after allocation some memory, and the size of requested memory could be 0, in this situation when malloc(0) returns NULL when you launch program with sanitizers everything will be fine, but if malloc(0) returns valid pointer when you launch program with memory sanitizers you will fault, so malloc(0) -> valid pointer make process of searching errors easier.
3. if malloc(0) is valid pointer, it makes malloc return code unique, so you can use the result of it as unique identifier of object, which can be useful on some cases.

Not sure, according to some random malloc source code I found, an input of 0 results in a return value of NULL. So it's a crazy way of setting the artist pointer to NULL.

http://www.raspberryginger.com/jbailey/minix/html/lib_2ansi_2malloc_8c-source.html

Its actually quite useful, and (obviously IMHO), the allowed behavior of returning a NULL pointer is broken. A dynamic pointer is useful not only for what it points at, but also the fact that it's address is unique. Returning NULL removes that second property. All of the embedded mallocs I program (quite frequently in fact) have this behavior.