From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/2580 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: malloc(0) behaviour Date: Mon, 14 Jan 2013 13:05:33 -0500 Message-ID: <20130114180533.GP20323@brightrain.aerifal.cx> References: Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1358186753 26210 80.91.229.3 (14 Jan 2013 18:05:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 14 Jan 2013 18:05:53 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-2581-gllmg-musl=m.gmane.org@lists.openwall.com Mon Jan 14 19:06:09 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 1TuoQ6-0004AB-Eg for gllmg-musl@plane.gmane.org; Mon, 14 Jan 2013 19:06:02 +0100 Original-Received: (qmail 25874 invoked by uid 550); 14 Jan 2013 18:05:45 -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 25866 invoked from network); 14 Jan 2013 18:05:45 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:2580 Archived-At: On Mon, Jan 14, 2013 at 06:17:47PM +0100, Igmar Palsenberg wrote: > Hi, > > 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. 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: http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_400.htm http://austingroupbugs.net/view.php?id=400 http://sourceware.org/bugzilla/show_bug.cgi?id=12547 Rich