From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=38450 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PmN7p-0001IH-T4 for qemu-devel@nongnu.org; Mon, 07 Feb 2011 04:11:15 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PmN7o-0005lz-Ck for qemu-devel@nongnu.org; Mon, 07 Feb 2011 04:11:13 -0500 Received: from mx1.redhat.com ([209.132.183.28]:39034) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PmN7o-0005lu-3g for qemu-devel@nongnu.org; Mon, 07 Feb 2011 04:11:12 -0500 Message-ID: <4D4FB794.8090404@redhat.com> Date: Mon, 07 Feb 2011 10:12:52 +0100 From: Kevin Wolf MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] block/vdi: Fix wrong size in conditionally used memset, memcmp References: <1296849676-7429-1-git-send-email-weil@mail.berlios.de> <4D4C5F47.8060700@codemonkey.ws> In-Reply-To: <4D4C5F47.8060700@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: QEMU Developers Am 04.02.2011 21:19, schrieb Anthony Liguori: > On 02/04/2011 02:01 PM, Stefan Weil wrote: >> Error report from cppcheck: >> block/vdi.c:122: error: Using sizeof for array given as function argument returns the size of pointer. >> block/vdi.c:128: error: Using sizeof for array given as function argument returns the size of pointer. >> >> Fix both by setting the correct size. >> >> The buggy code is only used when QEMU is build without uuid support. >> The bug is not critical, so there is no urgent need to apply it to >> old versions of QEMU. >> >> Cc: Kevin Wolf >> Signed-off-by: Stefan Weil Thanks, applied to the block branch. > Huh, I wouldn't have thought this was the case. I almost feel that > doing a #define UUID_SIZE may be better because sizeof(typeof(v)) != > sizeof(v) is weird even by C standards. I think typeof(uu) is actually unsigned char*, not unsigned char[16]. Strange semantics anyway... Kevin