[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 14 Jan 2013 13:05:33 -0500
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: malloc(0) behaviour
On Mon, Jan 14, 2013 at 06:17:47PM +0100, Igmar Palsenberg wrote:
> Hi,
>
> 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:
http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_400.htm
http://austingroupbugs.net/view.php?id=400
http://sourceware.org/bugzilla/show_bug.cgi?id=12547
Rich
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.
