|
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
[Prev in Thread] | Current Thread | [Next in Thread] |