[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANiq72=n4rVvmKt0RCb5aOfQydA8bgDxfntRLDieV8Q2efP8Zg@mail.gmail.com>
Date: Thu, 26 Nov 2020 18:05:45 +0100
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Geert Uytterhoeven <geert@...ux-m68k.org>
Cc: Edward Cree <ecree.xilinx@...il.com>,
ALSA Development Mailing List <alsa-devel@...a-project.org>,
linux-atm-general@...ts.sourceforge.net,
reiserfs-devel@...r.kernel.org, linux-iio@...r.kernel.org,
linux-wireless <linux-wireless@...r.kernel.org>,
Linux Fbdev development list <linux-fbdev@...r.kernel.org>,
dri-devel <dri-devel@...ts.freedesktop.org>,
"Gustavo A. R. Silva" <gustavoars@...nel.org>,
James Bottomley <James.Bottomley@...senpartnership.com>,
linux-ide@...r.kernel.org, dm-devel@...hat.com,
keyrings@...r.kernel.org,
MTD Maling List <linux-mtd@...ts.infradead.org>,
GR-everest-linux-l2@...vell.com, wcn36xx@...ts.infradead.org,
samba-technical@...ts.samba.org, linux-i3c@...ts.infradead.org,
linux1394-devel@...ts.sourceforge.net,
linux-afs@...ts.infradead.org,
usb-storage@...ts.one-eyed-alien.net,
Lars Ellenberg <drbd-dev@...ts.linbit.com>,
driverdevel <devel@...verdev.osuosl.org>,
linux-cifs@...r.kernel.org, rds-devel@....oracle.com,
Nick Desaulniers <ndesaulniers@...gle.com>,
scsi <linux-scsi@...r.kernel.org>,
Nathan Chancellor <natechancellor@...il.com>,
linux-rdma <linux-rdma@...r.kernel.org>,
oss-drivers@...ronome.com, bridge@...ts.linux-foundation.org,
linux-security-module <linux-security-module@...r.kernel.org>,
amd-gfx list <amd-gfx@...ts.freedesktop.org>,
linux-stm32@...md-mailman.stormreply.com, cluster-devel@...hat.com,
ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
coreteam@...filter.org, intel-wired-lan@...ts.osuosl.org,
linux-input <linux-input@...r.kernel.org>,
Miguel Ojeda <ojeda@...nel.org>,
Jakub Kicinski <kuba@...nel.org>,
Ext4 Developers List <linux-ext4@...r.kernel.org>,
Linux Media Mailing List <linux-media@...r.kernel.org>,
Kees Cook <keescook@...omium.org>, selinux@...r.kernel.org,
linux-arm-msm <linux-arm-msm@...r.kernel.org>,
Intel Graphics Development <intel-gfx@...ts.freedesktop.org>,
linux-geode@...ts.infradead.org, linux-can@...r.kernel.org,
linux-block@...r.kernel.org,
"open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
op-tee@...ts.trustedfirmware.org,
linux-mediatek@...ts.infradead.org, xen-devel@...ts.xenproject.org,
Nouveau Dev <nouveau@...ts.freedesktop.org>,
linux-hams@...r.kernel.org,
ceph-devel <ceph-devel@...r.kernel.org>,
virtualization@...ts.linux-foundation.org,
Linux ARM <linux-arm-kernel@...ts.infradead.org>,
linux-hwmon@...r.kernel.org,
Linux Watchdog Mailing List <linux-watchdog@...r.kernel.org>,
"open list:NFS, SUNRPC, AND..." <linux-nfs@...r.kernel.org>,
GR-Linux-NIC-Dev@...vell.com,
tipc-discussion@...ts.sourceforge.net,
Linux-MM <linux-mm@...ck.org>,
Network Development <netdev@...r.kernel.org>,
linux-decnet-user@...ts.sourceforge.net,
Linux MMC List <linux-mmc@...r.kernel.org>,
linux-kernel <linux-kernel@...r.kernel.org>,
"maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" <x86@...nel.org>,
Linux-Renesas <linux-renesas-soc@...r.kernel.org>,
linux-sctp@...r.kernel.org, USB list <linux-usb@...r.kernel.org>,
NetFilter <netfilter-devel@...r.kernel.org>,
Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
patches@...nsource.cirrus.com, Joe Perches <joe@...ches.com>,
linux-integrity <linux-integrity@...r.kernel.org>,
target-devel <target-devel@...r.kernel.org>,
linux-hardening@...r.kernel.org
Subject: Re: [PATCH 000/141] Fix fall-through warnings for Clang
On Thu, Nov 26, 2020 at 4:28 PM Geert Uytterhoeven <geert@...ux-m68k.org> wrote:
>
> The maintainer is not necessarily the owner/author of the code, and
> thus may not know the intent of the code.
Agreed, I was not blaming maintainers -- just trying to point out that
the problem is there :-)
In those cases, it is still very useful: we add the `fallthrough` and
a comment saying `FIXME: fallthrough intended? Figure this out...`.
Thus a previous unknown unknown is now a known unknown. And no new
unknown unknowns will be introduced since we enabled the warning
globally.
> BTW, you cannot mindlessly fix the latter, as you cannot know if
> "(a == b)" or "((a = b))" was intended, without understanding the code
> (and the (possibly unavailable) data sheet, and the hardware, ...).
That's right, I was referring to the cases where the compiler saves
someone time from a typo they just made.
Cheers,
Miguel
Powered by blists - more mailing lists