From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MA0nw-00026U-5i for qemu-devel@nongnu.org; Fri, 29 May 2009 08:03:20 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MA0nq-00021J-8L for qemu-devel@nongnu.org; Fri, 29 May 2009 08:03:18 -0400 Received: from [199.232.76.173] (port=48459 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MA0nq-000219-4q for qemu-devel@nongnu.org; Fri, 29 May 2009 08:03:14 -0400 Received: from srv-05.w4a.fr ([94.23.5.116]:53316 helo=mx1.w4a.fr) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MA0lT-0002Au-Si for qemu-devel@nongnu.org; Fri, 29 May 2009 08:00:48 -0400 Date: Fri, 29 May 2009 13:00:42 +0100 (GMT+01:00) From: jcd@tribudubois.net Message-ID: <9974029.69061243598442059.JavaMail.root@srv-05.w4a.fr> In-Reply-To: <2171027.69001243598252547.JavaMail.root@srv-05.w4a.fr> Subject: Re: [Qemu-devel] [PATCH] use qemu_malloc and friends consistently MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: qemu-devel@nongnu.org ----- "Kevin Wolf" a =C3=A9crit : > jcd@tribudubois.net schrieb: > > Kevin, > >=20 > > I certainly understand your goal ...=20 > >=20 > > Anyway, I will update my patche and resubmit. > >=20 > > 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. >=20 > 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 checkin= g 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 va= lue returned on succesfull malloc(0) and the value returned on a failed mal= loc(1000). So now, back to the malloc(0) case. Granted, it would be important to have a standard behavior of malloc() on a= ll 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() f= ailure schemes.=20 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.= =20 - If yes, we have to allow it for all platforms in qemu_alloc() [using mall= oc(1) under the cover for example] returning a valid/non NULL pointer for a= ll 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 compatibl= e in their behavior. None of these implementations are necessarily wrong, b= ut we just need to decide what is the allowed behavior for the qemu "platfo= rm" and then make sure that the qemu_malloc() implemetation is consistent o= n all underlying platforms. >=20 > Kevin