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

[Avi Kivity]

On 12/05/2009 07:28 PM, Blue Swirl wrote:
> On Sat, Dec 5, 2009 at 5:07 PM, Avi Kivity<address@hidden>  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.