[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: malc
Subject: Re: [Qemu-devel] [PATCH] use qemu_malloc and friends consistently
Date: Fri, 29 May 2009 19:06:59 +0400 (MSD)

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]