[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201120105344.4345c14e@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Date: Fri, 20 Nov 2020 10:53:44 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: "Gustavo A. R. Silva" <gustavoars@...nel.org>
Cc: linux-kernel@...r.kernel.org, alsa-devel@...a-project.org,
amd-gfx@...ts.freedesktop.org, bridge@...ts.linux-foundation.org,
ceph-devel@...r.kernel.org, cluster-devel@...hat.com,
coreteam@...filter.org, devel@...verdev.osuosl.org,
dm-devel@...hat.com, drbd-dev@...ts.linbit.com,
dri-devel@...ts.freedesktop.org, GR-everest-linux-l2@...vell.com,
GR-Linux-NIC-Dev@...vell.com, intel-gfx@...ts.freedesktop.org,
intel-wired-lan@...ts.osuosl.org, keyrings@...r.kernel.org,
linux1394-devel@...ts.sourceforge.net, linux-acpi@...r.kernel.org,
linux-afs@...ts.infradead.org,
linux-arm-kernel@...ts.infradead.org,
linux-arm-msm@...r.kernel.org,
linux-atm-general@...ts.sourceforge.net,
linux-block@...r.kernel.org, linux-can@...r.kernel.org,
linux-cifs@...r.kernel.org, linux-crypto@...r.kernel.org,
linux-decnet-user@...ts.sourceforge.net,
linux-ext4@...r.kernel.org, linux-fbdev@...r.kernel.org,
linux-geode@...ts.infradead.org, linux-gpio@...r.kernel.org,
linux-hams@...r.kernel.org, linux-hwmon@...r.kernel.org,
linux-i3c@...ts.infradead.org, linux-ide@...r.kernel.org,
linux-iio@...r.kernel.org, linux-input@...r.kernel.org,
linux-integrity@...r.kernel.org,
linux-mediatek@...ts.infradead.org, linux-media@...r.kernel.org,
linux-mmc@...r.kernel.org, linux-mm@...ck.org,
linux-mtd@...ts.infradead.org, linux-nfs@...r.kernel.org,
linux-rdma@...r.kernel.org, linux-renesas-soc@...r.kernel.org,
linux-scsi@...r.kernel.org, linux-sctp@...r.kernel.org,
linux-security-module@...r.kernel.org,
linux-stm32@...md-mailman.stormreply.com,
linux-usb@...r.kernel.org, linux-watchdog@...r.kernel.org,
linux-wireless@...r.kernel.org, netdev@...r.kernel.org,
netfilter-devel@...r.kernel.org, nouveau@...ts.freedesktop.org,
op-tee@...ts.trustedfirmware.org, oss-drivers@...ronome.com,
patches@...nsource.cirrus.com, rds-devel@....oracle.com,
reiserfs-devel@...r.kernel.org, samba-technical@...ts.samba.org,
selinux@...r.kernel.org, target-devel@...r.kernel.org,
tipc-discussion@...ts.sourceforge.net,
usb-storage@...ts.one-eyed-alien.net,
virtualization@...ts.linux-foundation.org,
wcn36xx@...ts.infradead.org, x86@...nel.org,
xen-devel@...ts.xenproject.org, linux-hardening@...r.kernel.org,
Nick Desaulniers <ndesaulniers@...gle.com>,
Nathan Chancellor <natechancellor@...il.com>,
Miguel Ojeda <ojeda@...nel.org>, Joe Perches <joe@...ches.com>,
Kees Cook <keescook@...omium.org>
Subject: Re: [PATCH 000/141] Fix fall-through warnings for Clang
On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:
> This series aims to fix almost all remaining fall-through warnings in
> order to enable -Wimplicit-fallthrough for Clang.
>
> In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> add multiple break/goto/return/fallthrough statements instead of just
> letting the code fall through to the next case.
>
> Notice that in order to enable -Wimplicit-fallthrough for Clang, this
> change[1] is meant to be reverted at some point. So, this patch helps
> to move in that direction.
>
> Something important to mention is that there is currently a discrepancy
> between GCC and Clang when dealing with switch fall-through to empty case
> statements or to cases that only contain a break/continue/return
> statement[2][3][4].
Are we sure we want to make this change? Was it discussed before?
Are there any bugs Clangs puritanical definition of fallthrough helped
find?
IMVHO compiler warnings are supposed to warn about issues that could
be bugs. Falling through to default: break; can hardly be a bug?!
Powered by blists - more mailing lists