qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] Permit zero-sized qemu_malloc() & friends


From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH] Permit zero-sized qemu_malloc() & friends
Date: Mon, 07 Dec 2009 09:50:58 -0600
User-agent: Thunderbird 2.0.0.23 (X11/20090825)

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.

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.

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?

Regards,

Anthony Liguori




reply via email to

[Prev in Thread] Current Thread [Next in Thread]