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

[malc <av1474@comtv.ru>]

On Fri, 29 May 2009, Anthony Liguori wrote:

> Paul Brook wrote:
> >> For the purpose of finding broken code returning NULL is IMHO the best
> >> option.  Although dereferencing NULL is undefined, in practice it will
> >> segfault in most cases so the bugs shouldn't stay unnoticed for long.
> >>     
> >
> > The best way to find broken code is to have qemu_malloc(0) abort, and avoid 
> > ever trying to allocate a zero size block. Returning NULL is liable to 
> > introduce extra bugs because code often attributes special meaning to NULL 
> > pointers. It also breaks pointer comparison.
> >
> > To some extent the answer to this question depends how much you trust your 
> > programmers. If you assume everyone knows the C standard well and always 
> > writes perfect code then malloc(0) is a legitimate technique, though IMHO of 
> > fairly limited benefit.
> >   
> 
> I disagree.  The wrong reason we introduced oom_check() was because we
> don't trust people to check returns.  Why would we trust them to check
> size arguments especially when a lot of programmers are not going to
> check size arguments by convention?
> 
> If we really want to fix up code, we can do so in a more benign way. 
> Instead of aborting, let's return malloc(1) and printf a warning.  Then
> we can fix sites without worrying about killing guests.

Printf a warning saying what exactly?

> 
> If we only have to fixup a few sites, then yeah, we can switch to
> abort().  If it turns out there's a ton of these things and the code is
> uglier, then we can give up and just accept these semantics.

We _already_ use abort, and so far only one caller was caught and
taken care of.

[..snip..]

-- 
mailto:av1474@comtv.ru