qemu-devel
[Top][All Lists]
Advanced

[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 13:00:42 +0100 (GMT+01:00)

----- "Kevin Wolf" <address@hidden> a écrit :

> address@hidden schrieb:
> > Kevin,
> > 
> > I certainly understand your goal ... 
> > 
> > Anyway, I will update my patche and resubmit.
> > 
> > BTW it has to be noted that most of the time the return value of
> malloc/qemu_malloc is not checked which can also prove problematic
> whatever the qemu_malloc/malloc behavior is.
> 
> It doesn't need to be checked, qemu_malloc never returns if it fails.
> If
> malloc(0) returns NULL (on success!) checking it is even wrong in
> places
> where this can happen.

I don't necessarily speak about the malloc(0) case.

Up to now the qemu_io code (for example) was using malloc() without checking 
for the returned value. If allocation fails, I believe it would be quite wrong 
to pass the returned (NULL) pointer to memcpy/memset/memcmp whatever platform 
you are considering ...

So it seems to me you definitively need a way to dicriminate between the value 
returned on succesfull malloc(0) and the value returned on a failed 
malloc(1000).

So now, back to the malloc(0) case.

Granted, it would be important to have a standard behavior of malloc() on all 
platforms to be able to check for failure. And malloc(0) returning NULL on 
success (on some plateform) is not very compatible with other malloc() failure 
schemes. 

qemu_malloc is a nice place to unify all the malloc() behavior. Now it just has 
to be decided for the "qemu platform" if we allow the malloc(0) usage. 
- If yes, we have to allow it for all platforms in qemu_alloc() [using 
malloc(1) under the cover for example] returning a valid/non NULL pointer for 
all underlying platforms (even the ones that were returning NULL on success).
- If not, we can just abort() to catch these case early as it is proposed.

It seems to be just a fact that all malloc implementation are not compatible in 
their behavior. None of these implementations are necessarily wrong, but we 
just need to decide what is the allowed behavior for the qemu "platform" and 
then make sure that the qemu_malloc() implemetation is consistent on all 
underlying platforms.

> 
> Kevin




reply via email to

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