lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <CAMuHMdV5kOakvZJMWLxbpigFPS+Xuw6DVYsWCWZy7wGsv3idcw@mail.gmail.com> Date: Thu, 26 Nov 2020 16:28:12 +0100 From: Geert Uytterhoeven <geert@...ux-m68k.org> To: Miguel Ojeda <miguel.ojeda.sandonis@...il.com> 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 Hi Miguel, On Thu, Nov 26, 2020 at 3:54 PM Miguel Ojeda <miguel.ojeda.sandonis@...il.com> wrote: > On Wed, Nov 25, 2020 at 11:44 PM Edward Cree <ecree.xilinx@...il.com> wrote: > > To make the intent clear, you have to first be certain that you > > understand the intent; otherwise by adding either a break or a > > fallthrough to suppress the warning you are just destroying the > > information that "the intent of this code is unknown". > > If you don't know what the intent of your own code is, then you > *already* have a problem in your hands. The maintainer is not necessarily the owner/author of the code, and thus may not know the intent of the code. > > or does it flag up code > > that can be mindlessly "fixed" (in which case the warning is > > worthless)? Proponents in this thread seem to be trying to > > have it both ways. > > A warning is not worthless just because you can mindlessly fix it. > There are many counterexamples, e.g. many > checkpatch/lint/lang-format/indentation warnings, functional ones like > the `if (a = b)` warning... 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, ...). P.S. So far I've stayed out of this thread, as I like it if the compiler flags possible mistakes. After all I was the one fixing new "may be used uninitialized" warnings thrown up by gcc-4.1, until (a bit later than) support for that compiler was removed... Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
Powered by blists - more mailing lists