From: Kevin Wolf <kwolf@redhat.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: qemu-devel@nongnu.org, hreitz@redhat.com, eblake@redhat.com,
vsementsov@yandex-team.ru, jsnow@redhat.com, idryomov@gmail.com,
pl@kamp.de, sw@weilnetz.de, sstabellini@kernel.org,
anthony.perard@citrix.com, paul@xen.org, pbonzini@redhat.com,
marcandre.lureau@redhat.com, berrange@redhat.com,
thuth@redhat.com, philmd@linaro.org, stefanha@redhat.com,
fam@euphon.net, quintela@redhat.com, peterx@redhat.com,
leobras@redhat.com, kraxel@redhat.com, qemu-block@nongnu.org,
xen-devel@lists.xenproject.org, alex.bennee@linaro.org,
peter.maydell@linaro.org
Subject: Re: [PATCH 6/7] block: Clean up local variable shadowing
Date: Fri, 15 Sep 2023 10:10:05 +0200 [thread overview]
Message-ID: <ZQQRXR7LP2fVrcMU@redhat.com> (raw)
In-Reply-To: <20230831132546.3525721-7-armbru@redhat.com>
Am 31.08.2023 um 15:25 hat Markus Armbruster geschrieben:
> Local variables shadowing other local variables or parameters make the
> code needlessly hard to understand. Tracked down with -Wshadow=local.
> Clean up: delete inner declarations when they are actually redundant,
> else rename variables.
>
> Signed-off-by: Markus Armbruster <armbru@redhat.com>
> ---
> block.c | 7 ++++---
> block/rbd.c | 2 +-
> block/stream.c | 1 -
> block/vvfat.c | 34 +++++++++++++++++-----------------
> hw/block/xen-block.c | 6 +++---
> 5 files changed, 25 insertions(+), 25 deletions(-)
I wonder why you made vdi a separate patch, but not vvfat, even though
that has more changes. (Of course, my selfish motivation for asking this
is that I could have given a R-b for it and wouldn't have to look at it
again in a v2 :-))
> diff --git a/block.c b/block.c
> index a307c151a8..7f0003d8ac 100644
> --- a/block.c
> +++ b/block.c
> @@ -3001,7 +3001,8 @@ static BdrvChild *bdrv_attach_child_common(BlockDriverState *child_bs,
> BdrvChildRole child_role,
> uint64_t perm, uint64_t shared_perm,
> void *opaque,
> - Transaction *tran, Error **errp)
> + Transaction *transaction,
> + Error **errp)
> {
> BdrvChild *new_child;
> AioContext *parent_ctx, *new_child_ctx;
> @@ -3088,7 +3089,7 @@ static BdrvChild *bdrv_attach_child_common(BlockDriverState *child_bs,
> .old_parent_ctx = parent_ctx,
> .old_child_ctx = child_ctx,
> };
> - tran_add(tran, &bdrv_attach_child_common_drv, s);
> + tran_add(transaction, &bdrv_attach_child_common_drv, s);
>
> if (new_child_ctx != child_ctx) {
> aio_context_release(new_child_ctx);
I think I would resolve this one the other way around. 'tran' is the
typical name for the parameter and it is the transaction that this
function should add things to.
The other one that shadows it is a local transaction that is completed
within the function. I think it's better if that one has a different
name.
As usual, being more specific than just 'tran' vs. 'transaction' would
be nice. Maybe 'aio_ctx_tran' for the nested one?
The rest looks okay.
Kevin
next prev parent reply other threads:[~2023-09-15 8:10 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-31 13:25 [PATCH 0/7] Steps towards enabling -Wshadow=local Markus Armbruster
2023-08-31 13:25 ` [PATCH 1/7] migration/rdma: Fix save_page method to fail on polling error Markus Armbruster
2023-08-31 13:38 ` Eric Blake
2023-09-19 5:40 ` Markus Armbruster
2023-08-31 20:17 ` Peter Xu
2023-09-06 3:48 ` Zhijian Li (Fujitsu)
2023-08-31 13:25 ` [PATCH 2/7] migration: Clean up local variable shadowing Markus Armbruster
2023-08-31 20:19 ` Peter Xu
2023-08-31 13:25 ` [PATCH 3/7] ui: " Markus Armbruster
2023-08-31 14:53 ` Peter Maydell
2023-09-01 8:11 ` Markus Armbruster
2023-08-31 13:25 ` [PATCH 4/7] block/dirty-bitmap: " Markus Armbruster
2023-08-31 19:29 ` Stefan Hajnoczi
2023-09-15 7:52 ` Kevin Wolf
2023-09-19 5:48 ` Markus Armbruster
2023-09-19 9:45 ` Kevin Wolf
2023-09-20 13:38 ` Markus Armbruster
2023-08-31 13:25 ` [PATCH 5/7] block/vdi: " Markus Armbruster
2023-08-31 19:26 ` Stefan Hajnoczi
2023-09-15 7:41 ` Kevin Wolf
2023-09-18 14:47 ` Markus Armbruster
2023-08-31 13:25 ` [PATCH 6/7] block: " Markus Armbruster
2023-08-31 19:24 ` Stefan Hajnoczi
2023-09-11 10:44 ` Anthony PERARD
2023-09-11 11:17 ` Ilya Dryomov
2023-09-15 8:10 ` Kevin Wolf [this message]
2023-09-18 14:49 ` Markus Armbruster
2023-08-31 13:25 ` [PATCH 7/7] qobject atomics osdep: Make a few macros more hygienic Markus Armbruster
2023-08-31 14:30 ` Eric Blake
2023-09-01 8:48 ` Markus Armbruster
2023-09-01 13:18 ` Eric Blake
2023-09-19 6:29 ` Markus Armbruster
2023-09-01 12:59 ` Cédric Le Goater
2023-09-01 14:31 ` Philippe Mathieu-Daudé
2023-09-01 14:50 ` Markus Armbruster
2023-09-01 14:54 ` Cédric Le Goater
2023-08-31 15:52 ` Richard Henderson
2023-09-01 8:12 ` Markus Armbruster
2023-09-01 8:05 ` [PATCH 0/7] Steps towards enabling -Wshadow=local Markus Armbruster
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZQQRXR7LP2fVrcMU@redhat.com \
--to=kwolf@redhat.com \
--cc=alex.bennee@linaro.org \
--cc=anthony.perard@citrix.com \
--cc=armbru@redhat.com \
--cc=berrange@redhat.com \
--cc=eblake@redhat.com \
--cc=fam@euphon.net \
--cc=hreitz@redhat.com \
--cc=idryomov@gmail.com \
--cc=jsnow@redhat.com \
--cc=kraxel@redhat.com \
--cc=leobras@redhat.com \
--cc=marcandre.lureau@redhat.com \
--cc=paul@xen.org \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=peterx@redhat.com \
--cc=philmd@linaro.org \
--cc=pl@kamp.de \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
--cc=sstabellini@kernel.org \
--cc=stefanha@redhat.com \
--cc=sw@weilnetz.de \
--cc=thuth@redhat.com \
--cc=vsementsov@yandex-team.ru \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).