From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1NHJtc-0007Z3-Et
	for qemu-devel@nongnu.org; Sun, 06 Dec 2009 11:23:40 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1NHJtW-0007YK-Rw
	for qemu-devel@nongnu.org; Sun, 06 Dec 2009 11:23:39 -0500
Received: from [199.232.76.173] (port=37951 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1NHJtW-0007YH-Jg
	for qemu-devel@nongnu.org; Sun, 06 Dec 2009 11:23:34 -0500
Received: from lo.gmane.org ([80.91.229.12]:39691)
	by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.60) (envelope-from <gceq-qemu-devel@m.gmane.org>)
	id 1NHJtW-0002sI-7a
	for qemu-devel@nongnu.org; Sun, 06 Dec 2009 11:23:34 -0500
Received: from list by lo.gmane.org with local (Exim 4.50) id 1NHJtT-0004JB-Aw
	for qemu-devel@nongnu.org; Sun, 06 Dec 2009 17:23:31 +0100
Received: from 85.93.118.17 ([85.93.118.17])
	by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
	id 1AlnuQ-0007hv-00
	for <qemu-devel@nongnu.org>; Sun, 06 Dec 2009 17:23:31 +0100
Received: from pbonzini by 85.93.118.17 with local (Gmexim 0.1 (Debian))
	id 1AlnuQ-0007hv-00
	for <qemu-devel@nongnu.org>; Sun, 06 Dec 2009 17:23:31 +0100
From: Paolo Bonzini <pbonzini@redhat.com>
Date: Sun, 06 Dec 2009 17:23:03 +0100
Message-ID: <hfglpa$r1s$1@ger.gmane.org>
References: <m3skbwxgkp.fsf@crossbow.pond.sub.org>	<4B193DA5.6040507@codemonkey.ws>	<m3zl5x1q5x.fsf@crossbow.pond.sub.org>	<Pine.LNX.4.64.0912051957430.3457@linmac.oyster.ru>	<m31vj8zg8s.fsf@crossbow.pond.sub.org>	<Pine.LNX.4.64.0912061132190.8894@linmac.oyster.ru>	<m3bpicwk8r.fsf@crossbow.pond.sub.org>	<Pine.LNX.4.64.0912061302550.9087@linmac.oyster.ru>	<hfg4t8$9sm$1@ger.gmane.org>
	<Pine.LNX.4.64.0912061501190.9249@linmac.oyster.ru>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
In-Reply-To: <Pine.LNX.4.64.0912061501190.9249@linmac.oyster.ru>
Sender: news <news@ger.gmane.org>
Subject: [Qemu-devel] Re: [PATCH] Permit zero-sized qemu_malloc() & friends
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org

On 12/06/2009 01:02 PM, malc wrote:
> On Sun, 6 Dec 2009, Paolo Bonzini wrote:
>
>> On 12/06/2009 11:22 AM, malc wrote:
>>> Here, i believe, you are inventing artificial restrictions on how
>>> malloc behaves, i don't see anything that prevents the implementor
>>> from setting aside a range of addresses with 31st bit set as an
>>> indicator of "zero" allocations, and then happily giving it to the
>>> user of malloc and consumming it in free.
>>
>> But it has to make it a valid address anyway.  If a zero-sized read treats it
>> as invalid (SIGSEGV, EFAULT, whatever), malloc has failed to return a valid
>> address and is not obeying its specification.
>
> Once again - standard doesn't speak about "valid addresses".

For that matter, POSIX doesn't mention EFAULT at all, and doesn't 
include detecting "valid addresses" among the things that read can do 
before returning 0.  So if an OS extends POSIX with EFAULT, it had 
better provide a malloc that is consistent with whatever definition of 
"valid address" EFAULT uses.  While if it doesn't provide EFAULT, read 
should return 0 for the OS to be conforming to POSIX, and the whole 
discussion is moot.

Paolo