From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60654) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VT6N6-0007lm-Ir for qemu-devel@nongnu.org; Mon, 07 Oct 2013 04:41:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VT6N0-0001jN-EU for qemu-devel@nongnu.org; Mon, 07 Oct 2013 04:40:56 -0400 Received: from mx.ipv6.kamp.de ([2a02:248:0:51::16]:40910 helo=mx01.kamp.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VT6N0-0001jB-2a for qemu-devel@nongnu.org; Mon, 07 Oct 2013 04:40:50 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Peter Lieven In-Reply-To: <20131007083830.GE6254@stefanha-thinkpad.redhat.com> Date: Mon, 7 Oct 2013 10:40:49 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5B71C7E1-B14F-4CC0-AC1E-20050BBE10F3@kamp.de> References: <1380029714-5239-1-git-send-email-pl@kamp.de> <1380029714-5239-21-git-send-email-pl@kamp.de> <524C53A9.6060607@redhat.com> <20131007083830.GE6254@stefanha-thinkpad.redhat.com> Subject: Re: [Qemu-devel] [PATCHv3 20/20] block/raw: copy BlockLimits on raw_open List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: kwolf@redhat.com, stefanha@redhat.com, ronniesahlberg@gmail.com, qemu-devel@nongnu.org, anthony@codemonkey.ws, pbonzini@redhat.com Am 07.10.2013 um 10:38 schrieb Stefan Hajnoczi : > On Wed, Oct 02, 2013 at 11:11:05AM -0600, Eric Blake wrote: >> On 09/24/2013 07:35 AM, Peter Lieven wrote: >>> Signed-off-by: Peter Lieven >>> --- >>> block/raw_bsd.c | 1 + >>> 1 file changed, 1 insertion(+) >>>=20 >>> diff --git a/block/raw_bsd.c b/block/raw_bsd.c >>> index 8dc7bba..7af26ad 100644 >>> --- a/block/raw_bsd.c >>> +++ b/block/raw_bsd.c >>> @@ -159,6 +159,7 @@ static int raw_open(BlockDriverState *bs, QDict = *options, int flags, >>> Error **errp) >>> { >>> bs->sg =3D bs->file->sg; >>> + memcpy(&bs->bl, &bs->file->bl, sizeof(struct BlockLimits)); >>=20 >> Personally, I think that sizeof(var) is more robust, because if the >> declaration of var is ever changed, you don't have to remember to = also >> touch up the memcpy. As in: >>=20 >> memcpy(&bs->bl, &bs->file->bl, sizeof(bs->bl)); >>=20 >> But there's plenty of examples of sizeof(type) in the codebase even = when >> a var is handy, so you are not alone, and that's not a reason for me = to >> request a respin. >>=20 >> On the other hand, why use memcpy() at all? >>=20 >> bs->bl =3D bs->file->bl; >>=20 >> should do the same trick, with less typing. >=20 > Yes, please use struct assignment. Okay, I was unsure because when looking at bdrv_move_feature_fields I = found that there memcpy was used. Peter=