From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/2601 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 13:33:07 +0100 Message-ID: <4FA1FD0D-5C34-4DE0-AF27-1F48BB194005@palsenberg.com> 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 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1358253198 6121 80.91.229.3 (15 Jan 2013 12:33:18 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 15 Jan 2013 12:33:18 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-2602-gllmg-musl=m.gmane.org@lists.openwall.com Tue Jan 15 13:33:36 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 1Tv5hv-0001Qk-Uf for gllmg-musl@plane.gmane.org; Tue, 15 Jan 2013 13:33:36 +0100 Original-Received: (qmail 27677 invoked by uid 550); 15 Jan 2013 12:33:19 -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 27669 invoked from network); 15 Jan 2013 12:33:19 -0000 In-Reply-To: <20130115110618.GA4468@port70.net> X-Mailer: Apple Mail (2.1499) Xref: news.gmane.org gmane.linux.lib.musl.general:2601 Archived-At: >> While the above is clear to me, returning a pointer that can't hold = anything just seems wrong to me. >=20 > 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 >=20 > but we can do a theoretical discussion about > the merits of malloc(0)!=3D0: >=20 > 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)=3D=3D0 That's there to access if size is 0 ? Sure, you can access : struct foo { }; which is size 0. I do wonder what that gives me in practice. That is, = not counting the fact that : if (size =3D=3D 0) size =3D 1; was a common practice in malloc() implementations a while ago. > 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=3D=3D0) >=20 > in rob pike's words "zero is a perfectly fine value" > http://code.google.com/p/go/issues/detail?id=3D4142#c2 He does have a point. If I go to the gas station, hang in the fuel = dispencer, pull it out again directly afterwards, and telling the guy = behind the desk that I didn't actually got fuel, I'm probably stared at :) My way of thinking is just different, and both are fine. =20 >> 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. >=20 > malloc(0) is implementation-defined with > two different conforming implementations >=20 > but either one you choose in practice a lot > of code will rely on the choosen behaviour > incorrectly >=20 > returning 0 does not save you from that >=20 > returning 0 has the drawback that realloc(0,0) > will be inconsistent > (either with the realloc(0,n)=3D=3D=3Dmalloc(n) assumption > or the realloc(p,0) failure reporting when p needs > to be freed) Agree. I always handle that case.=20 >=20 >> I'll wrap malloc() to include an abort in my case :) >=20 > 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 No, just in user code. Libraries shouldn't abort, I agree. In my case, = it only aborts in debug mode to aid testing. Igmar=