Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 15 Jan 2013 09:31:24 +0100
From: Igmar Palsenberg <>
Subject: Re: malloc(0) behaviour

>> Is there a (good) reason for Musl to follow glibc's malloc(0)
>> behaviour ? Musl returns a valid pointer, which is fine according to
>> the standard, but returning NULL is also fine.
> Yes, there are many good reasons. The most obvious (but stupid) one is
> that a huge number of programs will "replace" malloc with one where
> malloc(0) returns something other than a null pointer if the system's
> malloc(0) returns null, and this adds both bloat and risk of
> bugs/breakage from the replacement. But there are other much more
> fundamental reasons too. Basically they all come down to interactions
> between the requirements of malloc and realloc, and the fact that
> returning a null pointer from realloc means failure (and thus that the
> original object was not freed). I don't want to try to remember all
> the details at the moment (they're enough to make your brain hurt..)
> but here are some links to get you started on the issue:

While the above is clear to me, returning a pointer that can't hold anything just seems wrong to me.
It's also a matter of promoting bad code : Doing a malloc(0) is simply a bug. People are just to lazy to check return values,
and this makes the loop 3 lines shorter.

I'll wrap malloc() to include an abort in my case :)


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.