From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/2591 Path: news.gmane.org!not-for-mail From: Rob Landley Newsgroups: gmane.linux.lib.musl.general Subject: Re: malloc(0) behaviour Date: Mon, 14 Jan 2013 17:37:29 -0600 Message-ID: <1358206649.32505.21@driftwood> References: Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; DelSp=Yes; Format=Flowed Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1358206673 19677 80.91.229.3 (14 Jan 2013 23:37:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 14 Jan 2013 23:37:53 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-2592-gllmg-musl=m.gmane.org@lists.openwall.com Tue Jan 15 00:38:10 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 1TutbS-0003XX-0I for gllmg-musl@plane.gmane.org; Tue, 15 Jan 2013 00:38:06 +0100 Original-Received: (qmail 22313 invoked by uid 550); 14 Jan 2013 23:37:49 -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 22305 invoked from network); 14 Jan 2013 23:37:49 -0000 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:date:from:subject:to:in-reply-to:x-mailer:message-id :mime-version:content-type:content-disposition :content-transfer-encoding:x-gm-message-state; bh=yJp53R8tP5GnZgKbZEYeg9UWbTN1ufL5vX4pC1fWi/4=; b=HPQ8y4o9VvCb+QmvRhv//kCC/xu7HQDTSkxhVz8/PvXX3ke7YpD+tc7sPWjf1mxjDX 08xEE7yLVV2OGtUJiOwB6aeDTU+twZA/0peYxMODcJGaf7DT39w0RqUY7TW7kd9sQ99x 428wzxMzqvKIfllAsJiAeKjMFBGq8oYwVOYX5KwCZpXTs/X/5PfL2TJJsj6AcoysRRXY N5tSXMKu98UL8MGW97Tnm0+5ceTc/TF0owUILM+yHTzdK1UsXLoUcaBnTJaEt4d6/9dx A7ArD8HuIojZJ5/IvUtlmZoztMJQiV7EYRjMYqblMzAJ0Kp6G4M6dEk7QNSJ/Qnwrz4u 29kg== X-Received: by 10.182.218.37 with SMTP id pd5mr63099667obc.24.1358206657443; Mon, 14 Jan 2013 15:37:37 -0800 (PST) In-Reply-To: (from igmar@palsenberg.com on Mon Jan 14 11:17:47 2013) X-Mailer: Balsa 2.4.11 Content-Disposition: inline X-Gm-Message-State: ALoCoQnfZkx2N1//CjAe/boPsE80NhmkiA7r/vdCNv47SyXBor9HQoCU/eg/FcgTYZFh6e2qA0C2 Xref: news.gmane.org gmane.linux.lib.musl.general:2591 Archived-At: On 01/14/2013 11:17:47 AM, Igmar Palsenberg wrote: > Hi, >=20 > Is there a (good) reason for Musl to follow glibc's malloc(0) =20 > behaviour ? Because not doing so breaks some programs? (Dunno if it still does, but =20 last time I tried switching that config option off in uClibc the linux =20 from scratch build didn't finish.) > Musl returns a valid pointer, which is fine according > to the standard, but returning NULL is also fine. >=20 > IMHO, returning NULL is better : It usually kills the program if =20 > actual storage is > attempted. It also kills the program if they're checking the return code of =20 malloc() and treating NULL as an allocation failure indicator. NULL has =20 a defined meaning of "failed", when a zero length allocation is trivial =20 to satisfy and not necessarily wrong. Should a zero length file read return -1 instead of 0? Is it the =20 program's job to make sure it never makes a NOP syscall? Does adding =20 special case checks in your code to avoid such NOP calls actually make =20 the code smaller and simpler? > You also can't do that if a valid pointer > is returned, so I really can't grasp the reason for returning a =20 > pointer at all, Not indicating that the allocation failed and triggering an assert() =20 when there isn't actually a problem with a legitimately zero length =20 array that had nothing in it? (Both times I debugged why LFS stuff was =20 failing that's what it turned out to be, but I didn't spend too much =20 time on it before just switching the uClibc option on to support it.) > except to support buggy and lazy programming. You're defining "lazy" here a "not adding a special case in the caller =20 for every use of malloc()". That's certainly a point of view, but I'm =20 not sure that's the word you want to use for it. "Not sufficiently =20 defensive programming" maybe? Whether or not defensive programming is an improvement is one of those =20 perpetual arguments having to do with differing mindsets. In reality =20 the reason you'd want to do it is some libc implementations might _not_ =20 allow malloc(0) to succeed, and thus there are portability issues. But =20 only for people who care about portability off glibc, which is an =20 uphill battle in the first place. That said, "I'm right because other people might think like I do and =20 that would make me right" seems kind of a circular argument for a =20 position being _better_. If posix required a valid pointer to be =20 returned the positions would be reversed without any actual change in =20 the technical merits. And "posix doesn't require this, therefore let's intentional break it =20 to force any programs with technical posix compatability issues to use =20 a different libc rather than change anything to humor us"... not seeing =20 it. > I suggest we make malloc(0) return a NULL pointer. Any objections ? Only that it broke real world programs last time I tried it, but if you =20 don't care about that then by all means force 'em to use a different =20 libc. (Re: the "posix test" thread, having a ./configure --pedantic that =20 builds a musl without gnu/dammit extensions and safety tape over the =20 sharp bits sounds like a possible fun future thing. Having that be the =20 default, or adding a lot of runtime checks rather than commenting stuff =20 out at compile time, not so much...) Rob=