From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/2593 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:31:24 +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 1358238697 3597 80.91.229.3 (15 Jan 2013 08:31:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 15 Jan 2013 08:31:37 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-2594-gllmg-musl=m.gmane.org@lists.openwall.com Tue Jan 15 09:31:55 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 1Tv1w2-0006Xq-VU for gllmg-musl@plane.gmane.org; Tue, 15 Jan 2013 09:31:55 +0100 Original-Received: (qmail 31758 invoked by uid 550); 15 Jan 2013 08:31:37 -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 31748 invoked from network); 15 Jan 2013 08:31:37 -0000 In-Reply-To: <20130114180533.GP20323@brightrain.aerifal.cx> X-Mailer: Apple Mail (2.1499) Xref: news.gmane.org gmane.linux.lib.musl.general:2593 Archived-At: >> 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. >=20 > 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: >=20 > http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_400.htm > http://austingroupbugs.net/view.php?id=3D400 > http://sourceware.org/bugzilla/show_bug.cgi?id=3D12547 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=