From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/2590 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 18:05:55 -0500 Message-ID: <20130114230555.GT20323@brightrain.aerifal.cx> References: <20130114180533.GP20323@brightrain.aerifal.cx> 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 1358204770 3566 80.91.229.3 (14 Jan 2013 23:06:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 14 Jan 2013 23:06:10 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-2591-gllmg-musl=m.gmane.org@lists.openwall.com Tue Jan 15 00:06:27 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 1Tut6m-0002xU-Ot for gllmg-musl@plane.gmane.org; Tue, 15 Jan 2013 00:06:24 +0100 Original-Received: (qmail 10022 invoked by uid 550); 14 Jan 2013 23:06: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 10014 invoked from network); 14 Jan 2013 23:06:07 -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:2590 Archived-At: On Mon, Jan 14, 2013 at 05:22:16PM -0500, Strake wrote: > 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). > > 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. Yes. In any case, I don't see why a correct program would care what malloc(0) returns, since passing 0 to malloc just makes it harder to write a correct program. Normally after calling malloc, you check the return value, and handle it as an error if the return value is a null pointer. But if your program might pass 0 to malloc, you have to also consider the possibility that the null pointer was returned not as an error but as the "success" result for malloc(0). This greatly complicates your error handling; now you have to either clear errno first and check whether it's set after the call to malloc to determine whether allocation failed, or check for size==0 in the failure case and treat that specially as a sort of success. Things get even worse if you use realloc(p,0), especially if you want to support non-conforming implementations like glibc... Rich