[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 15 Jan 2013 09:31:24 +0100
From: Igmar Palsenberg <igmar@...senberg.com>
To: musl@...ts.openwall.com
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:
>
> 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
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 :)
Igmar
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.
