From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/2594 Path: news.gmane.org!not-for-mail From: Igmar Palsenberg Newsgroups: gmane.linux.lib.musl.general Subject: Re: malloc(0) behaviour Date: Tue, 15 Jan 2013 09:32:55 +0100 Message-ID: References: <20130114180533.GP20323@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1358238787 4192 80.91.229.3 (15 Jan 2013 08:33:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 15 Jan 2013 08:33:07 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-2595-gllmg-musl=m.gmane.org@lists.openwall.com Tue Jan 15 09:33:25 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1Tv1xU-0007rx-3M for gllmg-musl@plane.gmane.org; Tue, 15 Jan 2013 09:33:24 +0100 Original-Received: (qmail 32247 invoked by uid 550); 15 Jan 2013 08:33:07 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 32239 invoked from network); 15 Jan 2013 08:33:07 -0000 In-Reply-To: X-Mailer: Apple Mail (2.1499) Xref: news.gmane.org gmane.linux.lib.musl.general:2594 Archived-At: > On 14/01/2013, Rich Felker 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). >=20 > 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=