Date: Tue, 15 Jan 2013 09:32:55 +0100 From: Igmar Palsenberg <igmar@...senberg.com> To: musl@...ts.openwall.com Subject: Re: malloc(0) behaviour > On 14/01/2013, Rich Felker <dalias@...ifal.cx> wrote: >> 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). > > Another: Null means allocation failure. As malloc ought to never fail > to find zero bytes free, it thus makes sense to return a non-null > pointer. A valid pointer also means you should be able to store something. With malloc(0), you can't. If you ask me, abort() would be a same thing to do. And no, I don't expect a decent libc to actually do this :-) 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.