From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/2606 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: malloc(0) behaviour Date: Tue, 15 Jan 2013 08:46:34 -0500 Message-ID: <20130115134634.GX20323@brightrain.aerifal.cx> References: <20130114180533.GP20323@brightrain.aerifal.cx> <20130115110618.GA4468@port70.net> 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 1358257610 16245 80.91.229.3 (15 Jan 2013 13:46:50 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 15 Jan 2013 13:46:50 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-2607-gllmg-musl=m.gmane.org@lists.openwall.com Tue Jan 15 14:47:08 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 1Tv6r1-000895-Jv for gllmg-musl@plane.gmane.org; Tue, 15 Jan 2013 14:47:03 +0100 Original-Received: (qmail 28022 invoked by uid 550); 15 Jan 2013 13:46:46 -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 28014 invoked from network); 15 Jan 2013 13:46:46 -0000 Content-Disposition: inline In-Reply-To: <20130115110618.GA4468@port70.net> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:2606 Archived-At: On Tue, Jan 15, 2013 at 12:06:18PM +0100, Szabolcs Nagy wrote: > * Igmar Palsenberg [2013-01-15 09:31:24 +0100]: > > > 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 > > > > > > 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 > > > > While the above is clear to me, returning a pointer that can't hold anything just seems wrong to me. > > i don't think we have too many options here, > the standards and historical practices has > various inconsistencies and musl has the least > broken one > > but we can do a theoretical discussion about > the merits of malloc(0)!=0: > > i'm surprised that it "seems wrong" to you, > you can access the amount of bytes you requested > through the returned pointer p, evaluating > p+size is valid, p is suitably aligned for all > objects and it can be freed. > these assumptions are broken if malloc(0)==0 > > if the standard made malloc(0) work in ansi c > then it would save some branch logic and would > made the world a safer place > (because in a fair amount of code that gets > array length from external source no special > casing would be needed for length==0) In fairness, there's hardly any difference between the work involved in: if (size < LIMIT) and if (size-1 < LIMIT-1) The latter catches 0 and treats it as invalid. > > I'll wrap malloc() to include an abort in my case :) > > but don't do that in library code that may be > used in a long running process: allocation failures > should be reported to let the caller handle it I think he meant malloc(0) would abort to indicate that, in the rules of his project, malloc(0) is a programming error. This is not such a bad idea.. Rich