From: Eric Blake <eblake@redhat.com>
To: "Marc-André Lureau" <marcandre.lureau@gmail.com>
Cc: "Vladimir Sementsov-Ogievskiy" <vsementsov@yandex-team.ru>,
qemu-devel@nongnu.org, "Hyman Huang" <yong.huang@smartx.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Gerd Hoffmann" <kraxel@redhat.com>,
qemu-block@nongnu.org, "Kevin Wolf" <kwolf@redhat.com>,
"Fabiano Rosas" <farosas@suse.de>,
"Mahmoud Mandour" <ma.mandourr@gmail.com>,
"John Snow" <jsnow@redhat.com>,
"Klaus Jensen" <its@irrelevant.dk>, "Fam Zheng" <fam@euphon.net>,
"Eugenio Pérez" <eperezma@redhat.com>,
"Bin Meng" <bin.meng@windriver.com>,
"Hanna Reitz" <hreitz@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
"Stefan Hajnoczi" <stefanha@redhat.com>,
"Philippe Mathieu-Daudé" <philmd@linaro.org>,
"Yuval Shaia" <yuval.shaia.ml@gmail.com>,
"Alex Bennée" <alex.bennee@linaro.org>,
"Jesper Devantier" <foss@defmacro.it>,
"Pierrick Bouvier" <pierrick.bouvier@linaro.org>,
"Keith Busch" <kbusch@kernel.org>,
"Marcel Apfelbaum" <marcel.apfelbaum@gmail.com>,
"Alexandre Iooss" <erdnaxe@crans.org>,
"Peter Xu" <peterx@redhat.com>
Subject: Re: [PATCH 06/19] block/stream: fix -Werror=maybe-uninitialized false-positives
Date: Wed, 3 Apr 2024 12:50:45 -0500 [thread overview]
Message-ID: <7qztxyz6yrjir6odtguvfxnzmvpqfevxd3lnhmjldlk4br6cqc@iens4se43kj5> (raw)
In-Reply-To: <CAJ+F1CKAWpeOKe=8YM38_H6xP5cvDJ0RQXcSvm9LUMLpyo4ndw@mail.gmail.com>
On Wed, Apr 03, 2024 at 01:24:11PM +0400, Marc-André Lureau wrote:
> > > Unfortunately, it doesn't work in all cases. It seems to have issues
> > > with some guards:
> > > ../block/stream.c: In function ‘stream_run’:
> > > ../block/stream.c:216:12: error: ‘ret’ may be used uninitialized
> > > [-Werror=maybe-uninitialized]
> > > 216 | if (ret < 0) {
> > >
That one looks like:
int ret;
WITH_GRAPH_RDLOCK_GUARD() {
ret = ...;
}
if (copy) {
ret = ...;
}
if (ret < 0)
I suspect the compiler is seeing the uncertainty possible from the
second conditional, and letting it take priority over the certainty
that the tweaked macro provided for the first conditional.
> > >
> >
> > So, updated macro helps in some cases, but doesn't help here? Intersting, why.
> >
> > > What should we do? change the macros + cherry-pick the missing
> > > false-positives, or keep this series as is?
An uglier macro, with sufficient comments as to why it is ugly (in
order to let us have fewer false positives where we have to add
initializers) may be less churn in the code base, but I'm not
necessarily sold on the ugly macro. Let's see if anyone else
expresses an opinion.
> > >
> > >
> >
> > I think marco + missing is better. No reason to add dead-initializations in cases where new macros helps.
>
> Ok
>
> > Still, would be good to understand, what's the difference, why it help on some cases and not help in another.
>
> I don't know, it's like if the analyzer was lazy for this particular
> case, although there is nothing much different from other usages.
>
> If I replace:
> for (... *var2 = (void *)true; var2;
> with:
> for (... *var2 = (void *)true; var2 || true;
>
> then it doesn't warn..
but it also doesn't work. We want the body to execute exactly once,
not infloop.
>
> Interestingly as well, if I change:
> for (... *var2 = (void *)true; var2; var2 = NULL)
> for:
> for (... *var2 = GML_OBJ_(); var2; var2 = NULL)
>
> GML_OBJ_() simply being &(GraphLockable) { }), an empty compound
> literal, then it doesn't work, in all usages.
So the compiler is not figuring out that the compound literal is
sufficient for an unconditional one time through the for loop body.
What's worse, different compiler versions will change behavior over
time. Making the code ugly to pacify a particular compiler, when that
compiler might improve in the future, is a form of chasing windmills.
>
> All in all, I am not sure the trick of using var2 is really reliable either.
And that's my biggest argument for not making the macro not more
complex than it already is.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc.
Virtualization: qemu.org | libguestfs.org
next prev parent reply other threads:[~2024-04-03 17:52 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-28 10:20 [PATCH 00/19] -Werror=maybe-uninitialized fixes marcandre.lureau
2024-03-28 10:20 ` [PATCH 01/19] util/coroutine: fix -Werror=maybe-uninitialized false-positive marcandre.lureau
2024-04-02 20:17 ` Stefan Hajnoczi
2024-03-28 10:20 ` [PATCH 02/19] util/timer: with " marcandre.lureau
2024-03-28 10:20 ` [PATCH 03/19] hw/qxl: fix -Werror=maybe-uninitialized false-positives marcandre.lureau
2024-03-28 10:20 ` [PATCH 04/19] nbd: with -Werror=maybe-uninitialized false-positive marcandre.lureau
2024-03-28 14:30 ` Eric Blake
2024-03-28 10:20 ` [PATCH 05/19] block/mirror: fix " marcandre.lureau
2024-03-29 8:22 ` Vladimir Sementsov-Ogievskiy
2024-03-28 10:20 ` [PATCH 06/19] block/stream: fix -Werror=maybe-uninitialized false-positives marcandre.lureau
2024-03-29 8:34 ` Vladimir Sementsov-Ogievskiy
2024-04-02 9:12 ` Marc-André Lureau
2024-04-02 9:58 ` Vladimir Sementsov-Ogievskiy
2024-04-02 15:34 ` Eric Blake
2024-04-02 19:24 ` Vladimir Sementsov-Ogievskiy
2024-04-03 8:11 ` Marc-André Lureau
2024-04-03 8:31 ` Vladimir Sementsov-Ogievskiy
2024-04-03 9:24 ` Marc-André Lureau
2024-04-03 17:50 ` Eric Blake [this message]
2024-04-03 21:28 ` Vladimir Sementsov-Ogievskiy
2024-03-28 10:20 ` [PATCH 07/19] hw/ahci: fix -Werror=maybe-uninitialized false-positive marcandre.lureau
2024-03-28 10:20 ` [PATCH 08/19] hw/vhost-scsi: fix -Werror=maybe-uninitialized marcandre.lureau
2024-03-28 10:20 ` [PATCH 09/19] hw/sdhci: fix -Werror=maybe-uninitialized false-positive marcandre.lureau
2024-03-28 11:30 ` Philippe Mathieu-Daudé
2024-04-02 9:21 ` Marc-André Lureau
2024-03-28 10:20 ` [PATCH 10/19] hw/rdma: " marcandre.lureau
2024-03-28 10:20 ` [PATCH 11/19] migration/block: " marcandre.lureau
2024-03-28 19:40 ` Peter Xu
2024-03-28 10:20 ` [PATCH 12/19] migration: fix -Werror=maybe-uninitialized false-positives marcandre.lureau
2024-03-28 19:40 ` Peter Xu
2024-03-29 1:14 ` Yong Huang
2024-03-28 10:20 ` [PATCH 13/19] hw/virtio-blk: fix -Werror=maybe-uninitialized false-positive marcandre.lureau
2024-04-02 20:18 ` Stefan Hajnoczi
2024-03-28 10:20 ` [PATCH 14/19] plugins: " marcandre.lureau
2024-03-28 10:35 ` Pierrick Bouvier
2024-03-28 10:20 ` [PATCH 15/19] migration: " marcandre.lureau
2024-03-28 19:40 ` Peter Xu
2024-03-28 10:20 ` [PATCH 16/19] tests: fix -Werror=maybe-uninitialized marcandre.lureau
2024-03-28 10:20 ` [PATCH 17/19] hw/nvme: " marcandre.lureau
2024-04-02 10:40 ` Klaus Jensen
2024-03-28 10:20 ` [PATCH 18/19] hw/virtio: " marcandre.lureau
2024-03-28 10:20 ` [PATCH 19/19] RFC: hw/virtio: a potential leak fix marcandre.lureau
2024-03-28 14:31 ` [PATCH 00/19] -Werror=maybe-uninitialized fixes Eric Blake
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=7qztxyz6yrjir6odtguvfxnzmvpqfevxd3lnhmjldlk4br6cqc@iens4se43kj5 \
--to=eblake@redhat.com \
--cc=alex.bennee@linaro.org \
--cc=bin.meng@windriver.com \
--cc=eperezma@redhat.com \
--cc=erdnaxe@crans.org \
--cc=fam@euphon.net \
--cc=farosas@suse.de \
--cc=foss@defmacro.it \
--cc=hreitz@redhat.com \
--cc=its@irrelevant.dk \
--cc=jsnow@redhat.com \
--cc=kbusch@kernel.org \
--cc=kraxel@redhat.com \
--cc=kwolf@redhat.com \
--cc=ma.mandourr@gmail.com \
--cc=marcandre.lureau@gmail.com \
--cc=marcel.apfelbaum@gmail.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peterx@redhat.com \
--cc=philmd@linaro.org \
--cc=pierrick.bouvier@linaro.org \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.com \
--cc=vsementsov@yandex-team.ru \
--cc=yong.huang@smartx.com \
--cc=yuval.shaia.ml@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.