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.