From: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> To: Finn Thain <fthain@telegraphics.com.au> Cc: James Bottomley <James.Bottomley@hansenpartnership.com>, Kees Cook <keescook@chromium.org>, Jakub Kicinski <kuba@kernel.org>, "Gustavo A. R. Silva" <gustavoars@kernel.org>, linux-kernel <linux-kernel@vger.kernel.org>, alsa-devel@alsa-project.org, amd-gfx@lists.freedesktop.org, bridge@lists.linux-foundation.org, ceph-devel@vger.kernel.org, cluster-devel@redhat.com, coreteam@netfilter.org, devel@driverdev.osuosl.org, dm-devel@redhat.com, drbd-dev@lists.linbit.com, dri-devel@lists.freedesktop.org, GR-everest-linux-l2@marvell.com, GR-Linux-NIC-Dev@marvell.com, intel-gfx@lists.freedesktop.org, intel-wired-lan@lists.osuosl.org, keyrings@vger.kernel.org, linux1394-devel@lists.sourceforge.net, linux-acpi@vger.kernel.org, linux-afs@lists.infradead.org, Linux ARM <linux-arm-kernel@lists.infradead.org>, linux-arm-msm@vger.kernel.org, linux-atm-general@lists.sourceforge.net, linux-block@vger.kernel.org, linux-can@vger.kernel.org, linux-cifs@vger.kernel.org, Linux Crypto Mailing List <linux-crypto@vger.kernel.org>, linux-decnet-user@lists.sourceforge.net, Ext4 Developers List <linux-ext4@vger.kernel.org>, linux-fbdev@vger.kernel.org, linux-geode@lists.infradead.org, linux-gpio@vger.kernel.org, linux-hams@vger.kernel.org, linux-hwmon@vger.kernel.org, linux-i3c@lists.infradead.org, linux-ide@vger.kernel.org, linux-iio@vger.kernel.org, linux-input <linux-input@vger.kernel.org>, linux-integrity@vger.kernel.org, linux-mediatek@lists.infradead.org, Linux Media Mailing List <linux-media@vger.kernel.org>, linux-mmc@vger.kernel.org, Linux-MM <linux-mm@kvack.org>, linux-mtd@lists.infradead.org, linux-nfs@vger.kernel.org, linux-rdma@vger.kernel.org, linux-renesas-soc@vger.kernel.org, linux-scsi@vger.kernel.org, linux-sctp@vger.kernel.org, linux-security-module@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com, linux-usb@vger.kernel.org, linux-watchdog@vger.kernel.org, linux-wireless <linux-wireless@vger.kernel.org>, Network Development <netdev@vger.kernel.org>, netfilter-devel@vger.kernel.org, nouveau@lists.freedesktop.org, op-tee@lists.trustedfirmware.org, oss-drivers@netronome.com, patches@opensource.cirrus.com, rds-devel@oss.oracle.com, reiserfs-devel@vger.kernel.org, samba-technical@lists.samba.org, selinux@vger.kernel.org, target-devel@vger.kernel.org, tipc-discussion@lists.sourceforge.net, usb-storage@lists.one-eyed-alien.net, virtualization@lists.linux-foundation.org, wcn36xx@lists.infradead.org, "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" <x86@kernel.org>, xen-devel@lists.xenproject.org, linux-hardening@vger.kernel.org, Nick Desaulniers <ndesaulniers@google.com>, Nathan Chancellor <natechancellor@gmail.com>, Miguel Ojeda <ojeda@kernel.org>, Joe Perches <joe@perches.com> Subject: Re: [PATCH 000/141] Fix fall-through warnings for Clang Date: Wed, 25 Nov 2020 00:46:23 +0100 Message-ID: <CANiq72=Ybm2MHmOizo1xQ_QYGuvbthtnLbwCkr8AFb8PcfmuQw@mail.gmail.com> (raw) In-Reply-To: <alpine.LNX.2.23.453.2011241036520.7@nippy.intranet> On Tue, Nov 24, 2020 at 1:58 AM Finn Thain <fthain@telegraphics.com.au> wrote: > > What I meant was that you've used pessimism as if it was fact. "future mistakes that it might prevent" is neither pessimism nor states a fact. > For example, "There is no way to guess what the effect would be if the > compiler trained programmers to add a knee-jerk 'break' statement to avoid > a warning". It is only knee-jerk if you think you are infallible. > Moreover, what I meant was that preventing programmer mistakes is a > problem to be solved by development tools This warning comes from a development tool -- the compiler. > The idea that retro-fitting new > language constructs onto mature code is somehow necessary to "prevent > future mistakes" is entirely questionable. The kernel is not a frozen codebase. Further, "mature code vs. risk of change" arguments don't apply here because the semantics of the program and binary output isn't changing. > Sure. And if you put -Wimplicit-fallthrough into the Makefile and if that > leads to well-intentioned patches that cause regressions, it is partly on > you. Again: adding a `fallthrough` does not change the program semantics. If you are a maintainer and want to cross-check, compare the codegen. > Have you ever considered the overall cost of the countless > -Wpresume-incompetence flags? Yeah: negative. On the other hand, the overall cost of the countless -fI-am-infallible flags is very noticeable. > Perhaps you pay the power bill for a build farm that produces logs that > no-one reads? Perhaps you've run git bisect, knowing that the compiler > messages are not interesting? Or compiled software in using a language > that generates impenetrable messages? If so, here's a tip: > > # grep CFLAGS /etc/portage/make.conf > CFLAGS="... -Wno-all -Wno-extra ..." > CXXFLAGS="${CFLAGS}" > > Now allow me some pessimism: the hardware upgrades, gigawatt hours and > wait time attributable to obligatory static analyses are a net loss. If you really believe compiler warnings and static analysis are useless and costly, I think there is not much point in continuing the discussion. > No, it's not for me to prove that such patches don't affect code > generation. That's for the patch author and (unfortunately) for reviewers. I was not asking you to prove it. I am stating that proving it is very easy. Cheers, Miguel
next prev parent reply index Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-11-20 18:21 Gustavo A. R. Silva 2020-11-20 18:28 ` Joe Perches 2020-11-20 19:02 ` Gustavo A. R. Silva 2020-11-20 18:32 ` [PATCH 054/141] target: " Gustavo A. R. Silva 2020-11-20 18:53 ` [PATCH 000/141] " Jakub Kicinski 2020-11-20 19:04 ` Gustavo A. R. Silva 2020-11-20 19:30 ` Kees Cook 2020-11-20 19:51 ` Jakub Kicinski 2020-11-20 20:48 ` Kees Cook 2020-11-22 16:17 ` Kees Cook 2020-11-22 18:21 ` James Bottomley 2020-11-22 18:25 ` Joe Perches 2020-11-22 19:12 ` James Bottomley 2020-11-22 19:22 ` Joe Perches 2020-11-22 19:53 ` James Bottomley 2020-11-23 13:03 ` [Intel-wired-lan] " Gustavo A. R. Silva 2020-11-23 16:31 ` James Bottomley 2020-11-24 21:32 ` Kees Cook 2020-11-24 22:24 ` Finn Thain 2020-11-24 23:15 ` Miguel Ojeda 2020-11-24 23:53 ` Finn Thain 2020-11-25 1:05 ` Miguel Ojeda 2020-11-25 7:05 ` James Bottomley 2020-11-25 12:24 ` Nick Desaulniers 2020-11-25 21:33 ` Finn Thain 2020-11-25 22:09 ` Nick Desaulniers 2020-11-25 23:21 ` Finn Thain 2020-11-26 0:30 ` Finn Thain 2020-11-25 21:10 ` Kees Cook 2020-11-22 20:35 ` Miguel Ojeda 2020-11-22 22:36 ` James Bottomley 2020-11-23 14:19 ` Miguel Ojeda 2020-11-23 15:58 ` James Bottomley 2020-11-23 16:24 ` Rafael J. Wysocki 2020-11-23 16:32 ` Joe Perches 2020-11-23 18:56 ` Miguel Ojeda 2020-11-23 20:37 ` James Bottomley 2020-11-25 0:32 ` Miguel Ojeda 2020-11-25 22:44 ` Edward Cree 2020-11-26 14:53 ` Miguel Ojeda 2020-11-26 15:28 ` Geert Uytterhoeven 2020-11-26 16:18 ` Karol Herbst 2020-11-26 17:05 ` Miguel Ojeda 2020-11-25 10:38 ` Andy Shevchenko 2020-11-25 9:01 ` Sean Young 2020-11-22 22:54 ` Finn Thain 2020-11-22 23:04 ` James Bottomley 2020-11-23 14:05 ` Miguel Ojeda 2020-11-24 0:58 ` Finn Thain 2020-11-24 1:05 ` Joe Perches 2020-11-24 2:48 ` Finn Thain 2020-11-24 23:46 ` Miguel Ojeda [this message] 2020-11-22 22:10 ` Sam Ravnborg 2020-11-24 1:32 ` Nick Desaulniers 2020-11-24 21:25 ` Kees Cook 2020-11-25 23:02 ` Edward Cree 2020-12-01 14:08 ` Dan Carpenter 2020-12-01 14:04 ` Dan Carpenter 2020-11-20 22:21 ` Miguel Ojeda 2020-11-23 20:03 ` Jason Gunthorpe 2020-11-24 14:47 ` Gustavo A. R. Silva [not found] ` <160616392671.21180.16517492185091399884.b4-ty@kernel.org> 2020-11-24 14:47 ` Gustavo A. R. Silva 2020-12-01 5:52 ` Martin K. Petersen 2020-12-01 8:20 ` Gustavo A. R. Silva 2020-12-08 4:52 ` (subset) " Martin K. Petersen
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='CANiq72=Ybm2MHmOizo1xQ_QYGuvbthtnLbwCkr8AFb8PcfmuQw@mail.gmail.com' \ --to=miguel.ojeda.sandonis@gmail.com \ --cc=GR-Linux-NIC-Dev@marvell.com \ --cc=GR-everest-linux-l2@marvell.com \ --cc=James.Bottomley@hansenpartnership.com \ --cc=alsa-devel@alsa-project.org \ --cc=amd-gfx@lists.freedesktop.org \ --cc=bridge@lists.linux-foundation.org \ --cc=ceph-devel@vger.kernel.org \ --cc=cluster-devel@redhat.com \ --cc=coreteam@netfilter.org \ --cc=devel@driverdev.osuosl.org \ --cc=dm-devel@redhat.com \ --cc=drbd-dev@lists.linbit.com \ --cc=dri-devel@lists.freedesktop.org \ --cc=fthain@telegraphics.com.au \ --cc=gustavoars@kernel.org \ --cc=intel-gfx@lists.freedesktop.org \ --cc=intel-wired-lan@lists.osuosl.org \ --cc=joe@perches.com \ --cc=keescook@chromium.org \ --cc=keyrings@vger.kernel.org \ --cc=kuba@kernel.org \ --cc=linux-acpi@vger.kernel.org \ --cc=linux-afs@lists.infradead.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-arm-msm@vger.kernel.org \ --cc=linux-atm-general@lists.sourceforge.net \ --cc=linux-block@vger.kernel.org \ --cc=linux-can@vger.kernel.org \ --cc=linux-cifs@vger.kernel.org \ --cc=linux-crypto@vger.kernel.org \ --cc=linux-decnet-user@lists.sourceforge.net \ --cc=linux-ext4@vger.kernel.org \ --cc=linux-fbdev@vger.kernel.org \ --cc=linux-geode@lists.infradead.org \ --cc=linux-gpio@vger.kernel.org \ --cc=linux-hams@vger.kernel.org \ --cc=linux-hardening@vger.kernel.org \ --cc=linux-hwmon@vger.kernel.org \ --cc=linux-i3c@lists.infradead.org \ --cc=linux-ide@vger.kernel.org \ --cc=linux-iio@vger.kernel.org \ --cc=linux-input@vger.kernel.org \ --cc=linux-integrity@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-media@vger.kernel.org \ --cc=linux-mediatek@lists.infradead.org \ --cc=linux-mm@kvack.org \ --cc=linux-mmc@vger.kernel.org \ --cc=linux-mtd@lists.infradead.org \ --cc=linux-nfs@vger.kernel.org \ --cc=linux-rdma@vger.kernel.org \ --cc=linux-renesas-soc@vger.kernel.org \ --cc=linux-scsi@vger.kernel.org \ --cc=linux-sctp@vger.kernel.org \ --cc=linux-security-module@vger.kernel.org \ --cc=linux-stm32@st-md-mailman.stormreply.com \ --cc=linux-usb@vger.kernel.org \ --cc=linux-watchdog@vger.kernel.org \ --cc=linux-wireless@vger.kernel.org \ --cc=linux1394-devel@lists.sourceforge.net \ --cc=natechancellor@gmail.com \ --cc=ndesaulniers@google.com \ --cc=netdev@vger.kernel.org \ --cc=netfilter-devel@vger.kernel.org \ --cc=nouveau@lists.freedesktop.org \ --cc=ojeda@kernel.org \ --cc=op-tee@lists.trustedfirmware.org \ --cc=oss-drivers@netronome.com \ --cc=patches@opensource.cirrus.com \ --cc=rds-devel@oss.oracle.com \ --cc=reiserfs-devel@vger.kernel.org \ --cc=samba-technical@lists.samba.org \ --cc=selinux@vger.kernel.org \ --cc=target-devel@vger.kernel.org \ --cc=tipc-discussion@lists.sourceforge.net \ --cc=usb-storage@lists.one-eyed-alien.net \ --cc=virtualization@lists.linux-foundation.org \ --cc=wcn36xx@lists.infradead.org \ --cc=x86@kernel.org \ --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
Target-devel archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/target-devel/0 target-devel/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 target-devel target-devel/ https://lore.kernel.org/target-devel \ target-devel@vger.kernel.org public-inbox-index target-devel Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.target-devel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git