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

[Anthony Liguori <anthony@codemonkey.ws>]

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.

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.

Does that sound reasonable?

abort()'ing on malloc(0) is going to result in some really nasty crashes
that were entirely preventable in probably 99% of circumstances.

Regards,

Anthony Liguori

> If you want maximize chances of catching accidental mistakes as early as 
> possible then you should have malloc(0) abort, because it probably means 
> someone forgot tho consider the empty case.
>
> Paul
>
>
>