[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: jcd
Subject: Re: [Qemu-devel] [PATCH] use qemu_malloc and friends consistently
Date: Fri, 29 May 2009 14:35:40 +0100 (GMT+01:00)

So even if malloc(0) is legal per se, is it really exepected there is that much 
code in qemu relying on it?

It seems not (and there is also some qemu code considering NULL as a failure 
value regardless of the value of size parameter) and fixing the few places 
where this could be expected (like qemu-io.c) should not be a lot of work. All 
these "special" cases should be detected fairly quickly.


----- "Paul Brook" <address@hidden> a écrit :

> >(e) return malloc(0), without wrapping it into oom_check().
> This is the worst of both worlds.
> > 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
> 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.
> 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

reply via email to

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