From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MA0qt-0003TA-Ik for qemu-devel@nongnu.org; Fri, 29 May 2009 08:06:23 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MA0qo-0003QW-1K for qemu-devel@nongnu.org; Fri, 29 May 2009 08:06:22 -0400 Received: from [199.232.76.173] (port=43709 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MA0qn-0003QP-NF for qemu-devel@nongnu.org; Fri, 29 May 2009 08:06:17 -0400 Received: from mx2.redhat.com ([66.187.237.31]:37668) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MA0qn-0004jk-68 for qemu-devel@nongnu.org; Fri, 29 May 2009 08:06:17 -0400 Message-ID: <4A1FCF76.9070609@redhat.com> Date: Fri, 29 May 2009 14:05:10 +0200 From: Kevin Wolf MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] use qemu_malloc and friends consistently References: <9974029.69061243598442059.JavaMail.root@srv-05.w4a.fr> In-Reply-To: <9974029.69061243598442059.JavaMail.root@srv-05.w4a.fr> 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: jcd@tribudubois.net Cc: qemu-devel@nongnu.org jcd@tribudubois.net schrieb: > ----- "Kevin Wolf" a =C3=A9crit : >=20 >> jcd@tribudubois.net schrieb: >>> Kevin, >>> >>> I certainly understand your goal ...=20 >>> >>> 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. >=20 > I don't necessarily speak about the malloc(0) case. >=20 > Up to now the qemu_io code (for example) was using malloc() without che= cking for the returned value. If allocation fails, I believe it would be = quite wrong to pass the returned (NULL) pointer to memcpy/memset/memcmp w= hatever platform you are considering ... >=20 > So it seems to me you definitively need a way to dicriminate between th= e value returned on succesfull malloc(0) and the value returned on a fail= ed malloc(1000). I should not have mentioned the malloc(0) in this mail, it only adds to the confusion. What I wanted to say is that a failed qemu_malloc doesn't return anything because it aborts (this code is in oom_check). So the caller needs not and even cannot check for failure. Kevin