Re: [Qemu-devel] [PATCH] use qemu_malloc and friends consistently

[malc <av1474@comtv.ru>]

On Fri, 29 May 2009, Anthony Liguori wrote:

> Kevin Wolf wrote:
> > Since recently qemu_malloc behaves differently from malloc with size =
> > 0. This isn't allowed any more with qemu_malloc. So you need to check
> > for pattern_count == 0 and either print an error message or malloc a
> > different size, e.g. 1. I'm sure we don't want qemu-io to abort() in
> > such a case.
> >
> > Or we could start over with a lengthy discussion about fixing qemu_malloc...
> >   
> 
> Having qemu_malloc(0) abort is silly.  Returning NULL or returning
> malloc(1) are both reasonable options.

Dereference of NULL is UB[1] and dereferencing result of malloc(1) will
just plain work.

returning malloc(1) is the approach libiberty takes, readline opts to
abort on any malloc returning NULL, thus behaving like current qemu_malloc
on AIX and other OSes that opt to return NULL in *alloc(0) situation.

> 
> Putting the abort() in there is going to introduce a ton of subtle bugs,
> I vote for changing qemu_malloc() to have a sane behavior.

And those will be caught, given one a chance to analyze things, unlike
head in the sand approach of hoping things would just work.

After doing some research, after the aforementioned lengthy discussion,
the only free OS that straight-forwardly described what it does was
OpenBSD:

http://www.openbsd.org/cgi-bin/man.cgi?query=malloc&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html

P.S. So far the abort that went into qemu_malloc caught one usage of zero
     allocation (once again coming from qcow2).

[1] For instance on AIX (and HP/UX depending on some tunables) read from 
    NULL will just work also.

-- 
mailto:av1474@comtv.ru