From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60295) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XPzgG-0005MP-2C for qemu-devel@nongnu.org; Fri, 05 Sep 2014 16:00:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XPzgA-0000aZ-D4 for qemu-devel@nongnu.org; Fri, 05 Sep 2014 16:00:24 -0400 Received: from mx-v6.kamp.de ([2a02:248:0:51::16]:49094 helo=mx01.kamp.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XPzgA-0000Zb-2J for qemu-devel@nongnu.org; Fri, 05 Sep 2014 16:00:18 -0400 Message-ID: <540A164C.6090003@kamp.de> Date: Fri, 05 Sep 2014 22:00:12 +0200 From: Peter Lieven MIME-Version: 1.0 References: <1408699567-6940-1-git-send-email-pl@kamp.de> <1408699567-6940-2-git-send-email-pl@kamp.de> <53FB51B4.40400@redhat.com> In-Reply-To: <53FB51B4.40400@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 1/2] util: introduce bitmap_try_new List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake , qemu-devel@nongnu.org Cc: kwolf@redhat.com, pbonzini@redhat.com, stefanha@redhat.com Am 25.08.2014 um 17:09 schrieb Eric Blake: > On 08/22/2014 03:26 AM, Peter Lieven wrote: >> regular bitmap_new simply aborts if the memory allocation fails. >> bitmap_try_new returns NULL on failure and allows for proper >> error handling. >> >> Signed-off-by: Peter Lieven >> --- >> include/qemu/bitmap.h | 6 ++++++ >> 1 file changed, 6 insertions(+) >> >> diff --git a/include/qemu/bitmap.h b/include/qemu/bitmap.h >> index 1babd5d..51b430f 100644 >> --- a/include/qemu/bitmap.h >> +++ b/include/qemu/bitmap.h >> @@ -94,6 +94,12 @@ static inline unsigned long *bitmap_new(long nbits) >> return g_malloc0(len); >> } >> >> +static inline unsigned long *bitmap_try_new(long nbits) >> +{ >> + long len = BITS_TO_LONGS(nbits) * sizeof(unsigned long); >> + return g_try_malloc0(len); >> +} >> + > What you have works, but I personally would have reimplemented > bitmap_new as the first caller of bitmap_try_new in this patch, where > bitmap_new handles a NULL bitmap_try_new return by abort()ing, so that > it has the same behavior. By routing the one function to use the other, > we are future-proofing: if initialization of a bitmap ever needs > modification, we only update bitmap_try_new, rather than copying the > updates to both functions. > Good point. What would be the right exit if we receive a NULL from bitmap_try_new? abort() ? Peter