From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/2607 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:48:02 -0500 Message-ID: <20130115134802.GY20323@brightrain.aerifal.cx> References: <20130114180533.GP20323@brightrain.aerifal.cx> <20130115110618.GA4468@port70.net> <4FA1FD0D-5C34-4DE0-AF27-1F48BB194005@palsenberg.com> 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 1358257695 17096 80.91.229.3 (15 Jan 2013 13:48:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 15 Jan 2013 13:48:15 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-2608-gllmg-musl=m.gmane.org@lists.openwall.com Tue Jan 15 14:48:33 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 1Tv6sR-00017v-Js for gllmg-musl@plane.gmane.org; Tue, 15 Jan 2013 14:48:31 +0100 Original-Received: (qmail 29718 invoked by uid 550); 15 Jan 2013 13:48:15 -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 29710 invoked from network); 15 Jan 2013 13:48:14 -0000 Content-Disposition: inline In-Reply-To: <4FA1FD0D-5C34-4DE0-AF27-1F48BB194005@palsenberg.com> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:2607 Archived-At: On Tue, Jan 15, 2013 at 01:33:07PM +0100, Igmar Palsenberg wrote: > > > >> 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 > > That's there to access if size is 0 ? Sure, you can access : > > struct foo { > }; This is a constraint violation. C does not allow empty structs, and even if it did, they would not have size 0, since no type or object ever has size 0 in C. > > which is size 0. I do wonder what that gives me in practice. That is, not counting the fact that : > > if (size == 0) > size = 1; > > was a common practice in malloc() implementations a while ago. Of course, this is the canonical, simplest way to make malloc(0) return a unique pointer. Rich