[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 14 Jan 2013 17:22:16 -0500
From: Strake <strake888@...il.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.
Cheers,
Strake
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.
