[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 000/141] Fix fall-through warnings for Clang
- To: Finn Thain <fthain@xxxxxxxxxxxxxxxxxxx>
- From: Miguel Ojeda <miguel.ojeda.sandonis@xxxxxxxxx>
- Date: Wed, 25 Nov 2020 00:46:23 +0100
- Cc: James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx>, Kees Cook <keescook@xxxxxxxxxxxx>, Jakub Kicinski <kuba@xxxxxxxxxx>, "Gustavo A. R. Silva" <gustavoars@xxxxxxxxxx>, linux-kernel <linux-kernel@xxxxxxxxxxxxxxx>, alsa-devel@xxxxxxxxxxxxxxxx, amd-gfx@xxxxxxxxxxxxxxxxxxxxx, bridge@xxxxxxxxxxxxxxxxxxxxxxxxxx, ceph-devel@xxxxxxxxxxxxxxx, cluster-devel@xxxxxxxxxx, coreteam@xxxxxxxxxxxxx, devel@xxxxxxxxxxxxxxxxxxxx, dm-devel@xxxxxxxxxx, drbd-dev@xxxxxxxxxxxxxxxx, dri-devel@xxxxxxxxxxxxxxxxxxxxx, GR-everest-linux-l2@xxxxxxxxxxx, GR-Linux-NIC-Dev@xxxxxxxxxxx, intel-gfx@xxxxxxxxxxxxxxxxxxxxx, intel-wired-lan@xxxxxxxxxxxxxxxx, keyrings@xxxxxxxxxxxxxxx, linux1394-devel@xxxxxxxxxxxxxxxxxxxxx, linux-acpi@xxxxxxxxxxxxxxx, linux-afs@xxxxxxxxxxxxxxxxxxx, Linux ARM <linux-arm-kernel@xxxxxxxxxxxxxxxxxxx>, linux-arm-msm@xxxxxxxxxxxxxxx, linux-atm-general@xxxxxxxxxxxxxxxxxxxxx, linux-block@xxxxxxxxxxxxxxx, linux-can@xxxxxxxxxxxxxxx, linux-cifs@xxxxxxxxxxxxxxx, Linux Crypto Mailing List <linux-crypto@xxxxxxxxxxxxxxx>, linux-decnet-user@xxxxxxxxxxxxxxxxxxxxx, Ext4 Developers List <linux-ext4@xxxxxxxxxxxxxxx>, linux-fbdev@xxxxxxxxxxxxxxx, linux-geode@xxxxxxxxxxxxxxxxxxx, linux-gpio@xxxxxxxxxxxxxxx, linux-hams@xxxxxxxxxxxxxxx, linux-hwmon@xxxxxxxxxxxxxxx, linux-i3c@xxxxxxxxxxxxxxxxxxx, linux-ide@xxxxxxxxxxxxxxx, linux-iio@xxxxxxxxxxxxxxx, linux-input <linux-input@xxxxxxxxxxxxxxx>, linux-integrity@xxxxxxxxxxxxxxx, linux-mediatek@xxxxxxxxxxxxxxxxxxx, Linux Media Mailing List <linux-media@xxxxxxxxxxxxxxx>, linux-mmc@xxxxxxxxxxxxxxx, Linux-MM <linux-mm@xxxxxxxxx>, linux-mtd@xxxxxxxxxxxxxxxxxxx, linux-nfs@xxxxxxxxxxxxxxx, linux-rdma@xxxxxxxxxxxxxxx, linux-renesas-soc@xxxxxxxxxxxxxxx, linux-scsi@xxxxxxxxxxxxxxx, linux-sctp@xxxxxxxxxxxxxxx, linux-security-module@xxxxxxxxxxxxxxx, linux-stm32@xxxxxxxxxxxxxxxxxxxxxxxxxxxx, linux-usb@xxxxxxxxxxxxxxx, linux-watchdog@xxxxxxxxxxxxxxx, linux-wireless <linux-wireless@xxxxxxxxxxxxxxx>, Network Development <netdev@xxxxxxxxxxxxxxx>, netfilter-devel@xxxxxxxxxxxxxxx, nouveau@xxxxxxxxxxxxxxxxxxxxx, op-tee@xxxxxxxxxxxxxxxxxxxxxxxxx, oss-drivers@xxxxxxxxxxxxx, patches@xxxxxxxxxxxxxxxxxxxxx, rds-devel@xxxxxxxxxxxxxx, reiserfs-devel@xxxxxxxxxxxxxxx, samba-technical@xxxxxxxxxxxxxxx, selinux@xxxxxxxxxxxxxxx, target-devel@xxxxxxxxxxxxxxx, tipc-discussion@xxxxxxxxxxxxxxxxxxxxx, usb-storage@xxxxxxxxxxxxxxxxxxxxxxxx, virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx, wcn36xx@xxxxxxxxxxxxxxxxxxx, "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" <x86@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx, linux-hardening@xxxxxxxxxxxxxxx, Nick Desaulniers <ndesaulniers@xxxxxxxxxx>, Nathan Chancellor <natechancellor@xxxxxxxxx>, Miguel Ojeda <ojeda@xxxxxxxxxx>, Joe Perches <joe@xxxxxxxxxxx>
- Delivery-date: Tue, 24 Nov 2020 23:46:56 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On Tue, Nov 24, 2020 at 1:58 AM Finn Thain <fthain@xxxxxxxxxxxxxxxxxxx> 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
|