Anthony Liguori <anth...@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.
