Re: [PATCH] Make qemu_alloc()/qemu_realloc() return NULL for size==0 (was Re: [Qemu-devel] [PATCH] fix qemu_malloc() error check for size==0)

[Eduardo Habkost <ehabkost@redhat.com>]

On Tue, May 19, 2009 at 10:40:08PM +0400, malc wrote:
> On Tue, 19 May 2009, Eduardo Habkost wrote:
> 
> > On Tue, May 19, 2009 at 06:55:11PM +0400, malc wrote:
> > <snip>
> > > > > 
> > > > > That's the problem standard C does _not_ define the behaviour, and leaves
> > > > > that to implementation.
> > > > 
> > > > The only thing it doesn't define is either the returned pointer is NULL
> > > > or not, and that doesn't make malloc(0) automatically unportable,
> > > > because all the rest is perfectly defined:
> > > > 
> > > > 1) You can't dereference the pointer (just like you can't
> > > >    dereference p[n] on a malloc(n) block)
> > > > 2) You should pass the returned pointer to free() later
> > > > 
> > > 
> > > Alas your list is not exhaustive:
> > > 
> > >   3) Test the returned value against NULL
> > > 
> > > [Which is precisely what the qcow2 code did]
> > > 
> > [...]
> > > > 
> > > > I agree that expecting the Linux behaviour (non-NULL) is a bug. My point
> > > > is that there is no reason to consider malloc(0) a bug.
> > > 
> > > There is, due to the possibility of performing a 3) and a hard time 
> > > catching that (unless someone solves halting problem or subset applicable
> > > to QEMU thereof)
> > 
> > This is probably the only of your points which I agree with. What about
> > the following, then?
> > 
> > That would catch the cases you are worried about, but won't break
> > existing cases where malloc(0) is used correctly, and we won't be
> > creating a new malloc/free API that is incompabible from every other
> > malloc/free API out there.
> 
> Thanks for an attempt, but i don't like it either, since it sortof
> breaks the (unspoken?) qemu_malloc/realloc contract that those will
> never return NULL. I've commited the thing i had in mind.

Asking for feedback before committing wouldn't hurt.

Now:

- Every caller that could pass 0 to qemu_malloc() have to make it an
  special case.
- Every caller that uses qemu_realloc() will have to add special cases,
  if size==0 is possible.
- We are not sure where those callers are.
- Qemu's API is incompatible with every other malloc/free API out there,
  but is not documented

-- 
Eduardo