Date: Mon, 14 Jan 2013 18:05:55 -0500 From: Rich Felker <dalias@...ifal.cx> To: musl@...ts.openwall.com Subject: Re: malloc(0) behaviour On Mon, Jan 14, 2013 at 05:22:16PM -0500, Strake wrote: > 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. Yes. In any case, I don't see why a correct program would care what malloc(0) returns, since passing 0 to malloc just makes it harder to write a correct program. Normally after calling malloc, you check the return value, and handle it as an error if the return value is a null pointer. But if your program might pass 0 to malloc, you have to also consider the possibility that the null pointer was returned not as an error but as the "success" result for malloc(0). This greatly complicates your error handling; now you have to either clear errno first and check whether it's set after the call to malloc to determine whether allocation failed, or check for size==0 in the failure case and treat that specially as a sort of success. Things get even worse if you use realloc(p,0), especially if you want to support non-conforming implementations like glibc... 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.