From mboxrd@z Thu Jan  1 00:00:00 1970
X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/2589
Path: news.gmane.org!not-for-mail
From: Strake <strake888@gmail.com>
Newsgroups: gmane.linux.lib.musl.general
Subject: Re: malloc(0) behaviour
Date: Mon, 14 Jan 2013 17:22:16 -0500
Message-ID: <CAL3m8eCy9oUcJgheLf77GvxoZS4faXvvfUYug56Q=BM_c+digw@mail.gmail.com>
References: <F536F9AD-D97C-42FD-B453-02CC232845AF@palsenberg.com>
	<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=UTF-8
X-Trace: ger.gmane.org 1358202147 12113 80.91.229.3 (14 Jan 2013 22:22:27 GMT)
X-Complaints-To: usenet@ger.gmane.org
NNTP-Posting-Date: Mon, 14 Jan 2013 22:22:27 +0000 (UTC)
To: musl@lists.openwall.com
Original-X-From: musl-return-2590-gllmg-musl=m.gmane.org@lists.openwall.com Mon Jan 14 23:22:45 2013
Return-path: <musl-return-2590-gllmg-musl=m.gmane.org@lists.openwall.com>
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 <musl-return-2590-gllmg-musl=m.gmane.org@lists.openwall.com>)
	id 1TusQW-0008H6-Ak
	for gllmg-musl@plane.gmane.org; Mon, 14 Jan 2013 23:22:44 +0100
Original-Received: (qmail 20207 invoked by uid 550); 14 Jan 2013 22:22:27 -0000
Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm
Precedence: bulk
List-Post: <mailto:musl@lists.openwall.com>
List-Help: <mailto:musl-help@lists.openwall.com>
List-Unsubscribe: <mailto:musl-unsubscribe@lists.openwall.com>
List-Subscribe: <mailto:musl-subscribe@lists.openwall.com>
Original-Received: (qmail 20199 invoked from network); 14 Jan 2013 22:22:27 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        bh=guZjMlA+B4fnHF5QFBOnsIe5RYnWdhU0THi42/4GkVI=;
        b=vdc4CxeMdP/z/7LOnZeNTIrsMw5AqIUx8sH/nPVsRHRLJNF1Qn1d+BRnt4/orQPIeY
         yXczTvqnoZPIyThELttetPCHyOUfSFPi15oMqeqZEfO2jvjyAd4VZqbtva/zafPtj69z
         We3vOPdwYdTMMROuUXMTWdqk/jiRXFlnEMQ4+Xx7P1sBNB9XG4S9+EOkBTZM58Pafo7s
         MBoPtqBYoLhPajonIVy3gGQ1VRK9FtTMA9lHYFvJvaq+RTMj5D0R9qbGWn22Dr9MWX4j
         qOS/4iwOR/VoEOG+aExsu4r2irUV+7/F8xfJDpuWIzMoqXBWkOa7DGaTkY1dYWreL15T
         S1rQ==
In-Reply-To: <20130114180533.GP20323@brightrain.aerifal.cx>
Xref: news.gmane.org gmane.linux.lib.musl.general:2589
Archived-At: <http://permalink.gmane.org/gmane.linux.lib.musl.general/2589>

On 14/01/2013, Rich Felker <dalias@aerifal.cx> 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.

Cheers,
Strake