From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1NHvSr-0002RX-30
	for qemu-devel@nongnu.org; Tue, 08 Dec 2009 03:30:33 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1NHvSm-0002NQ-EJ
	for qemu-devel@nongnu.org; Tue, 08 Dec 2009 03:30:32 -0500
Received: from [199.232.76.173] (port=52950 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1NHvSm-0002NF-9v
	for qemu-devel@nongnu.org; Tue, 08 Dec 2009 03:30:28 -0500
Received: from mx1.redhat.com ([209.132.183.28]:6767)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <armbru@redhat.com>) id 1NHvSl-0002Sb-O6
	for qemu-devel@nongnu.org; Tue, 08 Dec 2009 03:30:27 -0500
From: Markus Armbruster <armbru@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] Permit zero-sized qemu_malloc() & friends
References: <m3skbwxgkp.fsf@crossbow.pond.sub.org>
	<4B1D2462.3070000@codemonkey.ws>
Date: Tue, 08 Dec 2009 09:30:16 +0100
In-Reply-To: <4B1D2462.3070000@codemonkey.ws> (Anthony Liguori's message of
	"Mon, 07 Dec 2009 09:50:58 -0600")
Message-ID: <m3pr6peulj.fsf@crossbow.pond.sub.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
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: Anthony Liguori <anthony@codemonkey.ws>
Cc: Kevin Wolf <kwolf@redhat.com>, Avi Kivity <avi@redhat.com>, Paul Brook <paul@codesourcery.com>, qemu-devel@nongnu.org

Anthony Liguori <anthony@codemonkey.ws> writes:

> Markus Armbruster wrote:
>> Commit a7d27b53 made zero-sized allocations a fatal error, deviating
>> from ISO C's malloc() & friends.  Revert that, but take care never to
>> return a null pointer, like malloc() & friends may do (it's
>> implementation defined), because that's another source of bugs.
>>   
>
> While it's always fun to argue about standards interpretation, I
> wanted to capture some action items from the discussion that I think
> there is agreement about.  Since I want to make changes for 0.12, I
> think it would be best to try and settle these now so we can do this
> before -rc2.
>
> For 0.12.0-rc2:
>
> I will send out a patch tonight or tomorrow changing qemu_malloc() to
> return malloc(1) when size=0 only for production builds (via
> --enable-zero-mallocs).  Development trees will maintain their current
> behavior.

I don't think 0.12 needs the compile-time option, it's a production
release after all.  But since I won't actually hurt 0.12, I don't mind.

> For 0.13:
>
> Someone (Marcus?) will introduce four new allocation functions.
>
> type *qemu_new(type, n_types);
> type *qemu_new0(type, n_types);
>
> type *qemu_renew(type, mem, n_types);
> type *qemu_renew0(type, mem, n_types);
>
> NB: The names are borrowed from glib.  I'm not tied to them.

I'll see what I can do post release.

> Will do our best to convert old code to use these functions where ever
> possible.  New code will be required to use these functions unless not
> possible.  n_types==0 is valid.  sizeof(type)==0 is valid.  Both
> circumstances return a unique non-NULL pointer.  If memory allocation
> fails, execution will abort.
>
> The existing qemu_malloc() will maintain it's current behavior (with
> the exception of the relaxed size==0 assertion for production
> releases).
>
> Does anyone object to this moving forward?

Thanks, works for me.