From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36125) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Um3Cj-00070J-LR for qemu-devel@nongnu.org; Mon, 10 Jun 2013 10:36:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Um3Cd-0004ZV-IL for qemu-devel@nongnu.org; Mon, 10 Jun 2013 10:36:17 -0400 Date: Mon, 10 Jun 2013 16:36:07 +0200 From: Kevin Wolf Message-ID: <20130610143607.GL3636@dhcp-200-207.str.redhat.com> References: <1370855253-7842-1-git-send-email-stefanha@redhat.com> <20130610140454.GI3636@dhcp-200-207.str.redhat.com> <20130610143223.GA4838@stefanha-thinkpad.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130610143223.GA4838@stefanha-thinkpad.redhat.com> Subject: Re: [Qemu-devel] [PATCH] vmdk: byteswap VMDK4Header.desc_offset field List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: Fam Zheng , qemu-devel@nongnu.org, Stefan Hajnoczi , qemu-stable@nongnu.org Am 10.06.2013 um 16:32 hat Stefan Hajnoczi geschrieben: > On Mon, Jun 10, 2013 at 04:04:55PM +0200, Kevin Wolf wrote: > > Am 10.06.2013 um 11:07 hat Stefan Hajnoczi geschrieben: > > > Remember to byteswap VMDK4Header.desc_offset on big-endian machines. > > > > > > Cc: qemu-stable@nongnu.org > > > Signed-off-by: Stefan Hajnoczi > > > > Thanks, applied to the block layer. > > > > > @@ -507,8 +507,11 @@ static int vmdk_open_vmdk4(BlockDriverState *bs, > > > if (ret < 0) { > > > return ret; > > > } > > > - if (header.capacity == 0 && header.desc_offset) { > > > - return vmdk_open_desc_file(bs, flags, header.desc_offset << 9); > > > + if (header.capacity == 0) { > > > + int64_t desc_offset = le64_to_cpu(header.desc_offset); > > > + if (desc_offset) { > > > + return vmdk_open_desc_file(bs, flags, desc_offset << 9); > > > + } > > > } > > > > Splitting up the if condition wouldn't have been necessary, strictly > > speaking. But I don't mind too much here. > > True. The reason I did it is because accessing header.desc_offset > directly is a bad habit. Someone modifying the code might conclude it's > safe to access directly when it actually only works for the limited > cases of zero and non-zero. It just looks a bit weird because you're still doing the same for header.capacity and there's no real reason for treating the two fields differently. Kevin