On 12/05/2009 07:28 PM, Blue Swirl wrote:
On Sat, Dec 5, 2009 at 5:07 PM, Avi Kivity<a...@redhat.com> wrote:
On 12/04/2009 06:49 PM, Anthony Liguori wrote:
I still believe that it is poor practice to pass size==0 to *malloc(). I
think actively discouraging this in qemu is a good thing because it's a
broken idiom.
Why? Unless we have a separate array allocator (like C++'s new and new[]),
we need to support zero-element arrays without pushing the burden to callers
(in the same way that for () supports zero iteration loops without a
separate if ()).
Running a loop zero or nonzero number of times always has a very clear
and precise meaning. A pointer returned from allocating zero or
nonzero number of items may be completely unusable or usable,
respectively.
Only if you allocate using POSIX malloc(). If you allocate using a
function that is defined to return a valid pointer for zero length
allocations, you're happy.
I think Laurent's proposal would work. We even could go so far as
rename the current function as qemu_malloc_possibly_broken (and adjust
callers mechanically) and introduce two new versions, which handle the
zero case in clearly advertised ways. Patches would fix the callers to
use the correct one
Good idea. Let's name the function that returns a valid pointer
qemu_malloc() (since that's what many callers expect anyway, and it's
fully backwards compatible), and see who calls
qemu_malloc_dont_call_me_with_zero().
Realistically, do we need two variants of malloc/realloc/free, or can we
stick with one that works for callers with a minimum of fuss?
--
Do not meddle in the internals of kernels, for they are subtle and quick to
panic.
