From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/2600 Path: news.gmane.org!not-for-mail From: Rob Landley Newsgroups: gmane.linux.lib.musl.general Subject: Re: malloc(0) behaviour Date: Tue, 15 Jan 2013 06:17:27 -0600 Message-ID: <1358252247.32505.23@driftwood> References: <20130115002442.GU20323@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; DelSp=Yes; Format=Flowed Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1358252268 28695 80.91.229.3 (15 Jan 2013 12:17:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 15 Jan 2013 12:17:48 +0000 (UTC) Cc: musl@lists.openwall.com To: musl@lists.openwall.com Original-X-From: musl-return-2601-gllmg-musl=m.gmane.org@lists.openwall.com Tue Jan 15 13:18:06 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 1Tv5Sp-0003y9-K0 for gllmg-musl@plane.gmane.org; Tue, 15 Jan 2013 13:17:59 +0100 Original-Received: (qmail 22490 invoked by uid 550); 15 Jan 2013 12:17:42 -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 22481 invoked from network); 15 Jan 2013 12:17:41 -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:cc:in-reply-to:x-mailer:message-id :mime-version:content-type:content-disposition :content-transfer-encoding:x-gm-message-state; bh=ESLpU0BamnyfpVgzs9nLz6ZfW6O8h+8P1wlemuBZKi0=; b=RMLt+0j4UdQAmHDDIdcfLmd9ausWAO8WEXx3V26z8ib31m2mFuEtf2bwVvXiAQRcB+ CzAFGpPiV+rzroW2lgsoDuR81l7PC0QhEQWSHDm7TtZDUuZ4UbLb+y2E4Lcn9fDZmHkp a5WuhyHuwy7jQH3OCvlsaMEuu9IXvZSGQyb3vrdQywGDG6KlJvP9RgJWhf8JaPbWb+Y7 Zrvf4WBDnly0l9cZdcUNVIQczD275aepSzzDGfXp1r8zHSwhXitPUtK/f1otyRk8Hu8t DW/cGbfGg3jkjxIgpCyXDROfd4C3PJdokflMQ8ph1pivdJ7VBvLg1pvcR7xUvkH3tHTk mYQQ== X-Received: by 10.60.31.51 with SMTP id x19mr53277718oeh.25.1358252250026; Tue, 15 Jan 2013 04:17:30 -0800 (PST) In-Reply-To: <20130115002442.GU20323@brightrain.aerifal.cx> (from dalias@aerifal.cx on Mon Jan 14 18:24:42 2013) X-Mailer: Balsa 2.4.11 Content-Disposition: inline X-Gm-Message-State: ALoCoQmbq2kjBDUlLrNVNva+gV5ZvOV67vvOT83CTDnfUQqFvd/ldinhXF9OEc6nfTde0JO411Yx Xref: news.gmane.org gmane.linux.lib.musl.general:2600 Archived-At: On 01/14/2013 06:24:42 PM, Rich Felker wrote: > > Not indicating that the allocation failed and triggering an assert() > > when there isn't actually a problem with a legitimately zero length > > array that had nothing in it? (Both times I debugged why LFS stuff > > was failing that's what it turned out to be, but I didn't spend too > > much time on it before just switching the uClibc option on to > > support it.) >=20 > While in some cases it would be nice to get a fault, you don't usually > get a fault when trying to access past the end of a length-1 array, so > why should you expect one when trying to access past the end of a > "length-0 array"? Nobody accessed it. They were doing something handwavingly like: if (!(array=3Dmalloc(sizeof(struct blah)*len))) die(); for (i=3D0; i > >except to support buggy and lazy programming. > > > > You're defining "lazy" here a "not adding a special case in the > > caller for every use of malloc()". That's certainly a point of view, > > but I'm not sure that's the word you want to use for it. "Not > > sufficiently defensive programming" maybe? >=20 > Well, doing nothing to account for the fact that malloc(0) "failing" > might not indicate a problematic OOM condition is "lazy" in my book. Maybe, but it means they're special casing 0, when otherwise it just =20 works. (At least on eglibc, and getting people to care about =20 portability off glibc remains a thing.) My point was that requiring them to special case this is not =20 necessarily an improvement. Rob=