From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7522AC8300F for ; Tue, 24 Nov 2020 00:59:45 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 44DF12075A for ; Tue, 24 Nov 2020 00:59:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729311AbgKXA6t (ORCPT ); Mon, 23 Nov 2020 19:58:49 -0500 Received: from kvm5.telegraphics.com.au ([98.124.60.144]:51159 "EHLO kvm5.telegraphics.com.au" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726803AbgKXA6q (ORCPT ); Mon, 23 Nov 2020 19:58:46 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by kvm5.telegraphics.com.au (Postfix) with ESMTP id 0EF842A8E0; Mon, 23 Nov 2020 19:58:39 -0500 (EST) Date: Tue, 24 Nov 2020 11:58:37 +1100 (AEDT) From: Finn Thain To: Miguel Ojeda cc: James Bottomley , Kees Cook , Jakub Kicinski , "Gustavo A. R. Silva" , linux-kernel , 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-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-decnet-user@lists.sourceforge.net, Ext4 Developers List , 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-integrity@vger.kernel.org, linux-mediatek@lists.infradead.org, Linux Media Mailing List , linux-mmc@vger.kernel.org, Linux-MM , 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 , Network Development , 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)" , xen-devel@lists.xenproject.org, linux-hardening@vger.kernel.org, Nick Desaulniers , Nathan Chancellor , Miguel Ojeda , Joe Perches Subject: Re: [PATCH 000/141] Fix fall-through warnings for Clang In-Reply-To: Message-ID: References: <20201120105344.4345c14e@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <202011201129.B13FDB3C@keescook> <20201120115142.292999b2@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <202011220816.8B6591A@keescook> <9b57fd4914b46f38d54087d75e072d6e947cb56d.camel@HansenPartnership.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org On Mon, 23 Nov 2020, Miguel Ojeda wrote: > On Mon, 23 Nov 2020, Finn Thain wrote: > > > On Sun, 22 Nov 2020, Miguel Ojeda wrote: > > > > > > > > It isn't that much effort, isn't it? Plus we need to take into > > > account the future mistakes that it might prevent, too. > > > > We should also take into account optimisim about future improvements > > in tooling. > > > Not sure what you mean here. There is no reliable way to guess what the > intention was with a missing fallthrough, even if you parsed whitespace > and indentation. > What I meant was that you've used pessimism as if it was 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". Moreover, what I meant was that preventing programmer mistakes is a problem to be solved by development tools. The idea that retro-fitting new language constructs onto mature code is somehow necessary to "prevent future mistakes" is entirely questionable. > > > So even if there were zero problems found so far, it is still a > > > positive change. > > > > > > > It is if you want to spin it that way. > > > How is that a "spin"? It is a fact that we won't get *implicit* > fallthrough mistakes anymore (in particular if we make it a hard error). > Perhaps "handwaving" is a better term? > > > I would agree if these changes were high risk, though; but they are > > > almost trivial. > > > > > > > This is trivial: > > > > case 1: > > this(); > > + fallthrough; > > case 2: > > that(); > > > > But what we inevitably get is changes like this: > > > > case 3: > > this(); > > + break; > > case 4: > > hmmm(); > > > > Why? Mainly to silence the compiler. Also because the patch author > > argued successfully that they had found a theoretical bug, often in > > mature code. > > > If someone changes control flow, that is on them. Every kernel developer > knows what `break` does. > 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. Have you ever considered the overall cost of the countless -Wpresume-incompetence flags? 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. > > But is anyone keeping score of the regressions? If unreported bugs > > count, what about unreported regressions? > > > Introducing `fallthrough` does not change semantics. If you are really > keen, you can always compare the objects because the generated code > shouldn't change. > 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. > Cheers, > Miguel > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B1629C2D0E4 for ; Tue, 24 Nov 2020 00:58:46 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 0D46720715 for ; Tue, 24 Nov 2020 00:58:45 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0D46720715 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=telegraphics.com.au Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 240356B005D; Mon, 23 Nov 2020 19:58:45 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 1F04E6B006E; Mon, 23 Nov 2020 19:58:45 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 107256B0070; Mon, 23 Nov 2020 19:58:45 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0125.hostedemail.com [216.40.44.125]) by kanga.kvack.org (Postfix) with ESMTP id D820D6B005D for ; Mon, 23 Nov 2020 19:58:44 -0500 (EST) Received: from smtpin26.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 8965E181AC9B6 for ; Tue, 24 Nov 2020 00:58:44 +0000 (UTC) X-FDA: 77517501768.26.cable84_5d0daf127369 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin26.hostedemail.com (Postfix) with ESMTP id 706131804B667 for ; Tue, 24 Nov 2020 00:58:44 +0000 (UTC) X-HE-Tag: cable84_5d0daf127369 X-Filterd-Recvd-Size: 7677 Received: from kvm5.telegraphics.com.au (kvm5.telegraphics.com.au [98.124.60.144]) by imf19.hostedemail.com (Postfix) with ESMTP for ; Tue, 24 Nov 2020 00:58:43 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by kvm5.telegraphics.com.au (Postfix) with ESMTP id 0EF842A8E0; Mon, 23 Nov 2020 19:58:39 -0500 (EST) Date: Tue, 24 Nov 2020 11:58:37 +1100 (AEDT) From: Finn Thain To: Miguel Ojeda cc: James Bottomley , Kees Cook , Jakub Kicinski , "Gustavo A. R. Silva" , linux-kernel , 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-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-decnet-user@lists.sourceforge.net, Ext4 Developers List , 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-integrity@vger.kernel.org, linux-mediatek@lists.infradead.org, Linux Media Mailing List , linux-mmc@vger.kernel.org, Linux-MM , 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 , Network Development , 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)" , xen-devel@lists.xenproject.org, linux-hardening@vger.kernel.org, Nick Desaulniers , Nathan Chancellor , Miguel Ojeda , Joe Perches Subject: Re: [PATCH 000/141] Fix fall-through warnings for Clang In-Reply-To: Message-ID: References: <20201120105344.4345c14e@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <202011201129.B13FDB3C@keescook> <20201120115142.292999b2@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <202011220816.8B6591A@keescook> <9b57fd4914b46f38d54087d75e072d6e947cb56d.camel@HansenPartnership.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon, 23 Nov 2020, Miguel Ojeda wrote: > On Mon, 23 Nov 2020, Finn Thain wrote: > > > On Sun, 22 Nov 2020, Miguel Ojeda wrote: > > > > > > > > It isn't that much effort, isn't it? Plus we need to take into > > > account the future mistakes that it might prevent, too. > > > > We should also take into account optimisim about future improvements > > in tooling. > > > Not sure what you mean here. There is no reliable way to guess what the > intention was with a missing fallthrough, even if you parsed whitespace > and indentation. > What I meant was that you've used pessimism as if it was 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". Moreover, what I meant was that preventing programmer mistakes is a problem to be solved by development tools. The idea that retro-fitting new language constructs onto mature code is somehow necessary to "prevent future mistakes" is entirely questionable. > > > So even if there were zero problems found so far, it is still a > > > positive change. > > > > > > > It is if you want to spin it that way. > > > How is that a "spin"? It is a fact that we won't get *implicit* > fallthrough mistakes anymore (in particular if we make it a hard error). > Perhaps "handwaving" is a better term? > > > I would agree if these changes were high risk, though; but they are > > > almost trivial. > > > > > > > This is trivial: > > > > case 1: > > this(); > > + fallthrough; > > case 2: > > that(); > > > > But what we inevitably get is changes like this: > > > > case 3: > > this(); > > + break; > > case 4: > > hmmm(); > > > > Why? Mainly to silence the compiler. Also because the patch author > > argued successfully that they had found a theoretical bug, often in > > mature code. > > > If someone changes control flow, that is on them. Every kernel developer > knows what `break` does. > 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. Have you ever considered the overall cost of the countless -Wpresume-incompetence flags? 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. > > But is anyone keeping score of the regressions? If unreported bugs > > count, what about unreported regressions? > > > Introducing `fallthrough` does not change semantics. If you are really > keen, you can always compare the objects because the generated code > shouldn't change. > 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. > Cheers, > Miguel > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2950BC63777 for ; Tue, 24 Nov 2020 17:18:24 +0000 (UTC) Received: from alsa0.perex.cz (alsa0.perex.cz [77.48.224.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 5A54D20643 for ; Tue, 24 Nov 2020 17:18:23 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=alsa-project.org header.i=@alsa-project.org header.b="Q/nO9+jO" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5A54D20643 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=telegraphics.com.au Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=alsa-devel-bounces@alsa-project.org Received: from alsa1.perex.cz (alsa1.perex.cz [207.180.221.201]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa0.perex.cz (Postfix) with ESMTPS id B1C5C181D; Tue, 24 Nov 2020 18:17:31 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz B1C5C181D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1606238301; bh=moZiL+z9jOfnUfbTpI/Tq2ZQcylfxaURYa8lRARJQgw=; h=Date:From:To:Subject:In-Reply-To:References:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=Q/nO9+jOfuXe0DIGgzGlFfk1B5Jr4M4sxcNO3QPEb1NWZsW2hoDwB0hQ30tS8qlE1 5z++i+siatJuRGqAgN66kTSLgpwi0CPvICaFEHpt80btB5rLt3D5V7mvPKlOsIh18R KlU46GT2n/mzvo7X4Ud9VNpNL2fkGjjUMxfZdoF0= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id A0765F8062D; Tue, 24 Nov 2020 17:58:56 +0100 (CET) Received: by alsa1.perex.cz (Postfix, from userid 50401) id E6C3CF80255; Tue, 24 Nov 2020 01:58:48 +0100 (CET) Received: from kvm5.telegraphics.com.au (kvm5.telegraphics.com.au [98.124.60.144]) by alsa1.perex.cz (Postfix) with ESMTP id 0559FF80113 for ; Tue, 24 Nov 2020 01:58:44 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz 0559FF80113 Received: from localhost (localhost.localdomain [127.0.0.1]) by kvm5.telegraphics.com.au (Postfix) with ESMTP id 0EF842A8E0; Mon, 23 Nov 2020 19:58:39 -0500 (EST) Date: Tue, 24 Nov 2020 11:58:37 +1100 (AEDT) From: Finn Thain To: Miguel Ojeda Subject: Re: [PATCH 000/141] Fix fall-through warnings for Clang In-Reply-To: Message-ID: References: <20201120105344.4345c14e@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <202011201129.B13FDB3C@keescook> <20201120115142.292999b2@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <202011220816.8B6591A@keescook> <9b57fd4914b46f38d54087d75e072d6e947cb56d.camel@HansenPartnership.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Mailman-Approved-At: Tue, 24 Nov 2020 17:58:07 +0100 Cc: alsa-devel@alsa-project.org, linux-atm-general@lists.sourceforge.net, reiserfs-devel@vger.kernel.org, linux-iio@vger.kernel.org, linux-wireless , linux-fbdev@vger.kernel.org, dri-devel@lists.freedesktop.org, "Gustavo A. R. Silva" , James Bottomley , linux-ide@vger.kernel.org, dm-devel@redhat.com, keyrings@vger.kernel.org, linux-mtd@lists.infradead.org, GR-everest-linux-l2@marvell.com, wcn36xx@lists.infradead.org, samba-technical@lists.samba.org, linux-i3c@lists.infradead.org, linux1394-devel@lists.sourceforge.net, linux-afs@lists.infradead.org, usb-storage@lists.one-eyed-alien.net, drbd-dev@lists.linbit.com, devel@driverdev.osuosl.org, linux-cifs@vger.kernel.org, rds-devel@oss.oracle.com, Nick Desaulniers , linux-scsi@vger.kernel.org, Nathan Chancellor , linux-rdma@vger.kernel.org, oss-drivers@netronome.com, bridge@lists.linux-foundation.org, linux-security-module@vger.kernel.org, amd-gfx@lists.freedesktop.org, linux-stm32@st-md-mailman.stormreply.com, cluster-devel@redhat.com, linux-acpi@vger.kernel.org, coreteam@netfilter.org, intel-wired-lan@lists.osuosl.org, linux-input , Miguel Ojeda , Jakub Kicinski , Ext4 Developers List , Linux Media Mailing List , Kees Cook , selinux@vger.kernel.org, linux-arm-msm@vger.kernel.org, intel-gfx@lists.freedesktop.org, linux-geode@lists.infradead.org, linux-can@vger.kernel.org, linux-block@vger.kernel.org, linux-gpio@vger.kernel.org, op-tee@lists.trustedfirmware.org, linux-mediatek@lists.infradead.org, xen-devel@lists.xenproject.org, nouveau@lists.freedesktop.org, linux-hams@vger.kernel.org, ceph-devel@vger.kernel.org, virtualization@lists.linux-foundation.org, Linux ARM , linux-hwmon@vger.kernel.org, linux-watchdog@vger.kernel.org, linux-nfs@vger.kernel.org, GR-Linux-NIC-Dev@marvell.com, tipc-discussion@lists.sourceforge.net, Linux-MM , Network Development , linux-decnet-user@lists.sourceforge.net, linux-mmc@vger.kernel.org, linux-kernel , "maintainer:X86 ARCHITECTURE \(32-BIT AND 64-BIT\)" , linux-renesas-soc@vger.kernel.org, linux-sctp@vger.kernel.org, linux-usb@vger.kernel.org, netfilter-devel@vger.kernel.org, Linux Crypto Mailing List , patches@opensource.cirrus.com, Joe Perches , linux-integrity@vger.kernel.org, target-devel@vger.kernel.org, linux-hardening@vger.kernel.org X-BeenThere: alsa-devel@alsa-project.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Alsa-devel mailing list for ALSA developers - http://www.alsa-project.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: "Alsa-devel" On Mon, 23 Nov 2020, Miguel Ojeda wrote: > On Mon, 23 Nov 2020, Finn Thain wrote: > > > On Sun, 22 Nov 2020, Miguel Ojeda wrote: > > > > > > > > It isn't that much effort, isn't it? Plus we need to take into > > > account the future mistakes that it might prevent, too. > > > > We should also take into account optimisim about future improvements > > in tooling. > > > Not sure what you mean here. There is no reliable way to guess what the > intention was with a missing fallthrough, even if you parsed whitespace > and indentation. > What I meant was that you've used pessimism as if it was 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". Moreover, what I meant was that preventing programmer mistakes is a problem to be solved by development tools. The idea that retro-fitting new language constructs onto mature code is somehow necessary to "prevent future mistakes" is entirely questionable. > > > So even if there were zero problems found so far, it is still a > > > positive change. > > > > > > > It is if you want to spin it that way. > > > How is that a "spin"? It is a fact that we won't get *implicit* > fallthrough mistakes anymore (in particular if we make it a hard error). > Perhaps "handwaving" is a better term? > > > I would agree if these changes were high risk, though; but they are > > > almost trivial. > > > > > > > This is trivial: > > > > case 1: > > this(); > > + fallthrough; > > case 2: > > that(); > > > > But what we inevitably get is changes like this: > > > > case 3: > > this(); > > + break; > > case 4: > > hmmm(); > > > > Why? Mainly to silence the compiler. Also because the patch author > > argued successfully that they had found a theoretical bug, often in > > mature code. > > > If someone changes control flow, that is on them. Every kernel developer > knows what `break` does. > 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. Have you ever considered the overall cost of the countless -Wpresume-incompetence flags? 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. > > But is anyone keeping score of the regressions? If unreported bugs > > count, what about unreported regressions? > > > Introducing `fallthrough` does not change semantics. If you are really > keen, you can always compare the objects because the generated code > shouldn't change. > 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. > Cheers, > Miguel > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2B065C2D0E4 for ; Tue, 24 Nov 2020 01:01:03 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id C69902073C for ; Tue, 24 Nov 2020 01:01:02 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="mfCLNsBw" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C69902073C Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=telegraphics.com.au Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-mtd-bounces+linux-mtd=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:MIME-Version:References:Message-ID:In-Reply-To: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=+xS4w7jFjVftRAUcAGN1hLrLoS7MjeUNqiz9AXbmJcY=; b=mfCLNsBwkcgL9AkZrQgsyIwgv 3n0uPIwCV8HhfPYT4LzsNdE7aYn7Wk1nFTG9LWNiOqlsgD0Qoe/da4CJPjBkUvhvYfnY26CSDe7YF r5AAt3sxNg8hSLzDg8qx12i6R+IGBCZEnCwsoYJe/W71ZYgQKrln0akVokAPO0U+lPMkKY1xWUTmL BWlDD634Ck2LRPGR0bqm8DUaXIEMiA/tkizVfeEGtm7MJ/YKNsP9H6+WdjxIEGjQ5vq93xtu6/SER UMaoYZYHf+BYzCUcU6F+2whySIWwdi9LRDK9LaL63xHkTLDoJJJ2OUh7kW0e3ZLjzAmMDN9c3dHaD NxKX2NoCQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1khMfY-0004wa-8c; Tue, 24 Nov 2020 00:58:56 +0000 Received: from kvm5.telegraphics.com.au ([98.124.60.144]) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1khMfO-0004uH-Hs; Tue, 24 Nov 2020 00:58:47 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by kvm5.telegraphics.com.au (Postfix) with ESMTP id 0EF842A8E0; Mon, 23 Nov 2020 19:58:39 -0500 (EST) Date: Tue, 24 Nov 2020 11:58:37 +1100 (AEDT) From: Finn Thain To: Miguel Ojeda Subject: Re: [PATCH 000/141] Fix fall-through warnings for Clang In-Reply-To: Message-ID: References: <20201120105344.4345c14e@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <202011201129.B13FDB3C@keescook> <20201120115142.292999b2@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <202011220816.8B6591A@keescook> <9b57fd4914b46f38d54087d75e072d6e947cb56d.camel@HansenPartnership.com> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201123_195846_722086_ED051A37 X-CRM114-Status: GOOD ( 25.82 ) X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: alsa-devel@alsa-project.org, linux-atm-general@lists.sourceforge.net, reiserfs-devel@vger.kernel.org, linux-iio@vger.kernel.org, linux-wireless , linux-fbdev@vger.kernel.org, dri-devel@lists.freedesktop.org, "Gustavo A. R. Silva" , James Bottomley , linux-ide@vger.kernel.org, dm-devel@redhat.com, keyrings@vger.kernel.org, linux-mtd@lists.infradead.org, GR-everest-linux-l2@marvell.com, wcn36xx@lists.infradead.org, samba-technical@lists.samba.org, linux-i3c@lists.infradead.org, linux1394-devel@lists.sourceforge.net, linux-afs@lists.infradead.org, usb-storage@lists.one-eyed-alien.net, drbd-dev@lists.linbit.com, devel@driverdev.osuosl.org, linux-cifs@vger.kernel.org, rds-devel@oss.oracle.com, Nick Desaulniers , linux-scsi@vger.kernel.org, Nathan Chancellor , linux-rdma@vger.kernel.org, oss-drivers@netronome.com, bridge@lists.linux-foundation.org, linux-security-module@vger.kernel.org, amd-gfx@lists.freedesktop.org, linux-stm32@st-md-mailman.stormreply.com, cluster-devel@redhat.com, linux-acpi@vger.kernel.org, coreteam@netfilter.org, intel-wired-lan@lists.osuosl.org, linux-input , Miguel Ojeda , Jakub Kicinski , Ext4 Developers List , Linux Media Mailing List , Kees Cook , selinux@vger.kernel.org, linux-arm-msm@vger.kernel.org, intel-gfx@lists.freedesktop.org, linux-geode@lists.infradead.org, linux-can@vger.kernel.org, linux-block@vger.kernel.org, linux-gpio@vger.kernel.org, op-tee@lists.trustedfirmware.org, linux-mediatek@lists.infradead.org, xen-devel@lists.xenproject.org, nouveau@lists.freedesktop.org, linux-hams@vger.kernel.org, ceph-devel@vger.kernel.org, virtualization@lists.linux-foundation.org, Linux ARM , linux-hwmon@vger.kernel.org, linux-watchdog@vger.kernel.org, linux-nfs@vger.kernel.org, GR-Linux-NIC-Dev@marvell.com, tipc-discussion@lists.sourceforge.net, Linux-MM , Network Development , linux-decnet-user@lists.sourceforge.net, linux-mmc@vger.kernel.org, linux-kernel , "maintainer:X86 ARCHITECTURE \(32-BIT AND 64-BIT\)" , linux-renesas-soc@vger.kernel.org, linux-sctp@vger.kernel.org, linux-usb@vger.kernel.org, netfilter-devel@vger.kernel.org, Linux Crypto Mailing List , patches@opensource.cirrus.com, Joe Perches , linux-integrity@vger.kernel.org, target-devel@vger.kernel.org, linux-hardening@vger.kernel.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-mtd" Errors-To: linux-mtd-bounces+linux-mtd=archiver.kernel.org@lists.infradead.org On Mon, 23 Nov 2020, Miguel Ojeda wrote: > On Mon, 23 Nov 2020, Finn Thain wrote: > > > On Sun, 22 Nov 2020, Miguel Ojeda wrote: > > > > > > > > It isn't that much effort, isn't it? Plus we need to take into > > > account the future mistakes that it might prevent, too. > > > > We should also take into account optimisim about future improvements > > in tooling. > > > Not sure what you mean here. There is no reliable way to guess what the > intention was with a missing fallthrough, even if you parsed whitespace > and indentation. > What I meant was that you've used pessimism as if it was 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". Moreover, what I meant was that preventing programmer mistakes is a problem to be solved by development tools. The idea that retro-fitting new language constructs onto mature code is somehow necessary to "prevent future mistakes" is entirely questionable. > > > So even if there were zero problems found so far, it is still a > > > positive change. > > > > > > > It is if you want to spin it that way. > > > How is that a "spin"? It is a fact that we won't get *implicit* > fallthrough mistakes anymore (in particular if we make it a hard error). > Perhaps "handwaving" is a better term? > > > I would agree if these changes were high risk, though; but they are > > > almost trivial. > > > > > > > This is trivial: > > > > case 1: > > this(); > > + fallthrough; > > case 2: > > that(); > > > > But what we inevitably get is changes like this: > > > > case 3: > > this(); > > + break; > > case 4: > > hmmm(); > > > > Why? Mainly to silence the compiler. Also because the patch author > > argued successfully that they had found a theoretical bug, often in > > mature code. > > > If someone changes control flow, that is on them. Every kernel developer > knows what `break` does. > 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. Have you ever considered the overall cost of the countless -Wpresume-incompetence flags? 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. > > But is anyone keeping score of the regressions? If unreported bugs > > count, what about unreported regressions? > > > Introducing `fallthrough` does not change semantics. If you are really > keen, you can always compare the objects because the generated code > shouldn't change. > 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. > Cheers, > Miguel > ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 61321C56202 for ; Tue, 24 Nov 2020 00:58:56 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id D0C9920715 for ; Tue, 24 Nov 2020 00:58:55 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="UV33jtqt" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D0C9920715 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=telegraphics.com.au Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-mediatek-bounces+linux-mediatek=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:MIME-Version:References:Message-ID:In-Reply-To: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=Cl9SycQmbUh3m1AhWHSIne6uyUoOszNz3IxnEWUMJnk=; b=UV33jtqta2Qd+zGgM5sw4Y1Fe WmKFHaiLBZsNfxoz4iIrh2RqqOpns6aWEcatiuzGQ+R/YNOGHJso9DAgmvEiEvvJKfHmXUK9Q007S Pt1VOuXqQo7C3QGqpuyFsIo4Gcb7Y6f3nCxvPZ57wrvc7ehGGxnxjA+cgNk0c9SPSLCy1T6J6Un0a 5T3IVTSrbomruhAzGniATQySnW9MHNcvPcHDQSUHtXN0FuWPok2upQcdjCFUQtc1ix1HzFiFs5fSv WhziuaukSOA1jGSwmyXPU34WXH9SyeZIthLWVPAWJyO5f5tD5Fp1C4BLmAhfuZb0J3uuDiZglUqhQ a3cP/En1w==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1khMfT-0004wH-30; Tue, 24 Nov 2020 00:58:51 +0000 Received: from kvm5.telegraphics.com.au ([98.124.60.144]) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1khMfO-0004uH-Hs; Tue, 24 Nov 2020 00:58:47 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by kvm5.telegraphics.com.au (Postfix) with ESMTP id 0EF842A8E0; Mon, 23 Nov 2020 19:58:39 -0500 (EST) Date: Tue, 24 Nov 2020 11:58:37 +1100 (AEDT) From: Finn Thain To: Miguel Ojeda Subject: Re: [PATCH 000/141] Fix fall-through warnings for Clang In-Reply-To: Message-ID: References: <20201120105344.4345c14e@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <202011201129.B13FDB3C@keescook> <20201120115142.292999b2@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <202011220816.8B6591A@keescook> <9b57fd4914b46f38d54087d75e072d6e947cb56d.camel@HansenPartnership.com> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201123_195846_722086_ED051A37 X-CRM114-Status: GOOD ( 25.82 ) X-BeenThere: linux-mediatek@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: alsa-devel@alsa-project.org, linux-atm-general@lists.sourceforge.net, reiserfs-devel@vger.kernel.org, linux-iio@vger.kernel.org, linux-wireless , linux-fbdev@vger.kernel.org, dri-devel@lists.freedesktop.org, "Gustavo A. R. Silva" , James Bottomley , linux-ide@vger.kernel.org, dm-devel@redhat.com, keyrings@vger.kernel.org, linux-mtd@lists.infradead.org, GR-everest-linux-l2@marvell.com, wcn36xx@lists.infradead.org, samba-technical@lists.samba.org, linux-i3c@lists.infradead.org, linux1394-devel@lists.sourceforge.net, linux-afs@lists.infradead.org, usb-storage@lists.one-eyed-alien.net, drbd-dev@lists.linbit.com, devel@driverdev.osuosl.org, linux-cifs@vger.kernel.org, rds-devel@oss.oracle.com, Nick Desaulniers , linux-scsi@vger.kernel.org, Nathan Chancellor , linux-rdma@vger.kernel.org, oss-drivers@netronome.com, bridge@lists.linux-foundation.org, linux-security-module@vger.kernel.org, amd-gfx@lists.freedesktop.org, linux-stm32@st-md-mailman.stormreply.com, cluster-devel@redhat.com, linux-acpi@vger.kernel.org, coreteam@netfilter.org, intel-wired-lan@lists.osuosl.org, linux-input , Miguel Ojeda , Jakub Kicinski , Ext4 Developers List , Linux Media Mailing List , Kees Cook , selinux@vger.kernel.org, linux-arm-msm@vger.kernel.org, intel-gfx@lists.freedesktop.org, linux-geode@lists.infradead.org, linux-can@vger.kernel.org, linux-block@vger.kernel.org, linux-gpio@vger.kernel.org, op-tee@lists.trustedfirmware.org, linux-mediatek@lists.infradead.org, xen-devel@lists.xenproject.org, nouveau@lists.freedesktop.org, linux-hams@vger.kernel.org, ceph-devel@vger.kernel.org, virtualization@lists.linux-foundation.org, Linux ARM , linux-hwmon@vger.kernel.org, linux-watchdog@vger.kernel.org, linux-nfs@vger.kernel.org, GR-Linux-NIC-Dev@marvell.com, tipc-discussion@lists.sourceforge.net, Linux-MM , Network Development , linux-decnet-user@lists.sourceforge.net, linux-mmc@vger.kernel.org, linux-kernel , "maintainer:X86 ARCHITECTURE \(32-BIT AND 64-BIT\)" , linux-renesas-soc@vger.kernel.org, linux-sctp@vger.kernel.org, linux-usb@vger.kernel.org, netfilter-devel@vger.kernel.org, Linux Crypto Mailing List , patches@opensource.cirrus.com, Joe Perches , linux-integrity@vger.kernel.org, target-devel@vger.kernel.org, linux-hardening@vger.kernel.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "Linux-mediatek" Errors-To: linux-mediatek-bounces+linux-mediatek=archiver.kernel.org@lists.infradead.org On Mon, 23 Nov 2020, Miguel Ojeda wrote: > On Mon, 23 Nov 2020, Finn Thain wrote: > > > On Sun, 22 Nov 2020, Miguel Ojeda wrote: > > > > > > > > It isn't that much effort, isn't it? Plus we need to take into > > > account the future mistakes that it might prevent, too. > > > > We should also take into account optimisim about future improvements > > in tooling. > > > Not sure what you mean here. There is no reliable way to guess what the > intention was with a missing fallthrough, even if you parsed whitespace > and indentation. > What I meant was that you've used pessimism as if it was 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". Moreover, what I meant was that preventing programmer mistakes is a problem to be solved by development tools. The idea that retro-fitting new language constructs onto mature code is somehow necessary to "prevent future mistakes" is entirely questionable. > > > So even if there were zero problems found so far, it is still a > > > positive change. > > > > > > > It is if you want to spin it that way. > > > How is that a "spin"? It is a fact that we won't get *implicit* > fallthrough mistakes anymore (in particular if we make it a hard error). > Perhaps "handwaving" is a better term? > > > I would agree if these changes were high risk, though; but they are > > > almost trivial. > > > > > > > This is trivial: > > > > case 1: > > this(); > > + fallthrough; > > case 2: > > that(); > > > > But what we inevitably get is changes like this: > > > > case 3: > > this(); > > + break; > > case 4: > > hmmm(); > > > > Why? Mainly to silence the compiler. Also because the patch author > > argued successfully that they had found a theoretical bug, often in > > mature code. > > > If someone changes control flow, that is on them. Every kernel developer > knows what `break` does. > 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. Have you ever considered the overall cost of the countless -Wpresume-incompetence flags? 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. > > But is anyone keeping score of the regressions? If unreported bugs > > count, what about unreported regressions? > > > Introducing `fallthrough` does not change semantics. If you are really > keen, you can always compare the objects because the generated code > shouldn't change. > 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. > Cheers, > Miguel > _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6C644C56201 for ; Tue, 24 Nov 2020 08:09:16 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id ED243206E0 for ; Tue, 24 Nov 2020 08:09:15 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org ED243206E0 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=telegraphics.com.au Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 1C8CD6E220; Tue, 24 Nov 2020 08:08:52 +0000 (UTC) Received: from kvm5.telegraphics.com.au (kvm5.telegraphics.com.au [98.124.60.144]) by gabe.freedesktop.org (Postfix) with ESMTP id A5D506E162; Tue, 24 Nov 2020 00:58:45 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by kvm5.telegraphics.com.au (Postfix) with ESMTP id 0EF842A8E0; Mon, 23 Nov 2020 19:58:39 -0500 (EST) Date: Tue, 24 Nov 2020 11:58:37 +1100 (AEDT) From: Finn Thain To: Miguel Ojeda Subject: Re: [PATCH 000/141] Fix fall-through warnings for Clang In-Reply-To: Message-ID: References: <20201120105344.4345c14e@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <202011201129.B13FDB3C@keescook> <20201120115142.292999b2@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <202011220816.8B6591A@keescook> <9b57fd4914b46f38d54087d75e072d6e947cb56d.camel@HansenPartnership.com> MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 24 Nov 2020 08:08:40 +0000 X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: alsa-devel@alsa-project.org, linux-atm-general@lists.sourceforge.net, reiserfs-devel@vger.kernel.org, linux-iio@vger.kernel.org, linux-wireless , linux-fbdev@vger.kernel.org, dri-devel@lists.freedesktop.org, "Gustavo A. R. Silva" , James Bottomley , linux-ide@vger.kernel.org, dm-devel@redhat.com, keyrings@vger.kernel.org, linux-mtd@lists.infradead.org, GR-everest-linux-l2@marvell.com, wcn36xx@lists.infradead.org, samba-technical@lists.samba.org, linux-i3c@lists.infradead.org, linux1394-devel@lists.sourceforge.net, linux-afs@lists.infradead.org, usb-storage@lists.one-eyed-alien.net, drbd-dev@lists.linbit.com, devel@driverdev.osuosl.org, linux-cifs@vger.kernel.org, rds-devel@oss.oracle.com, Nick Desaulniers , linux-scsi@vger.kernel.org, Nathan Chancellor , linux-rdma@vger.kernel.org, oss-drivers@netronome.com, bridge@lists.linux-foundation.org, linux-security-module@vger.kernel.org, amd-gfx@lists.freedesktop.org, linux-stm32@st-md-mailman.stormreply.com, cluster-devel@redhat.com, linux-acpi@vger.kernel.org, coreteam@netfilter.org, intel-wired-lan@lists.osuosl.org, linux-input , Miguel Ojeda , Jakub Kicinski , Ext4 Developers List , Linux Media Mailing List , Kees Cook , selinux@vger.kernel.org, linux-arm-msm@vger.kernel.org, intel-gfx@lists.freedesktop.org, linux-geode@lists.infradead.org, linux-can@vger.kernel.org, linux-block@vger.kernel.org, linux-gpio@vger.kernel.org, op-tee@lists.trustedfirmware.org, linux-mediatek@lists.infradead.org, xen-devel@lists.xenproject.org, nouveau@lists.freedesktop.org, linux-hams@vger.kernel.org, ceph-devel@vger.kernel.org, virtualization@lists.linux-foundation.org, target-devel@vger.kernel.org, Linux ARM , linux-hwmon@vger.kernel.org, linux-watchdog@vger.kernel.org, linux-nfs@vger.kernel.org, GR-Linux-NIC-Dev@marvell.com, tipc-discussion@lists.sourceforge.net, Linux-MM , Network Development , linux-decnet-user@lists.sourceforge.net, linux-mmc@vger.kernel.org, linux-kernel , linux-renesas-soc@vger.kernel.org, linux-sctp@vger.kernel.org, linux-usb@vger.kernel.org, netfilter-devel@vger.kernel.org, Linux Crypto Mailing List , patches@opensource.cirrus.com, Joe Perches , linux-integrity@vger.kernel.org, "maintainer:X86 ARCHITECTURE \(32-BIT AND 64-BIT\)" , linux-hardening@vger.kernel.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Mon, 23 Nov 2020, Miguel Ojeda wrote: > On Mon, 23 Nov 2020, Finn Thain wrote: > > > On Sun, 22 Nov 2020, Miguel Ojeda wrote: > > > > > > > > It isn't that much effort, isn't it? Plus we need to take into > > > account the future mistakes that it might prevent, too. > > > > We should also take into account optimisim about future improvements > > in tooling. > > > Not sure what you mean here. There is no reliable way to guess what the > intention was with a missing fallthrough, even if you parsed whitespace > and indentation. > What I meant was that you've used pessimism as if it was 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". Moreover, what I meant was that preventing programmer mistakes is a problem to be solved by development tools. The idea that retro-fitting new language constructs onto mature code is somehow necessary to "prevent future mistakes" is entirely questionable. > > > So even if there were zero problems found so far, it is still a > > > positive change. > > > > > > > It is if you want to spin it that way. > > > How is that a "spin"? It is a fact that we won't get *implicit* > fallthrough mistakes anymore (in particular if we make it a hard error). > Perhaps "handwaving" is a better term? > > > I would agree if these changes were high risk, though; but they are > > > almost trivial. > > > > > > > This is trivial: > > > > case 1: > > this(); > > + fallthrough; > > case 2: > > that(); > > > > But what we inevitably get is changes like this: > > > > case 3: > > this(); > > + break; > > case 4: > > hmmm(); > > > > Why? Mainly to silence the compiler. Also because the patch author > > argued successfully that they had found a theoretical bug, often in > > mature code. > > > If someone changes control flow, that is on them. Every kernel developer > knows what `break` does. > 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. Have you ever considered the overall cost of the countless -Wpresume-incompetence flags? 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. > > But is anyone keeping score of the regressions? If unreported bugs > > count, what about unreported regressions? > > > Introducing `fallthrough` does not change semantics. If you are really > keen, you can always compare the objects because the generated code > shouldn't change. > 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. > Cheers, > Miguel > _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 59BD3C2D0E4 for ; Tue, 24 Nov 2020 08:54:28 +0000 (UTC) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 923222075A for ; Tue, 24 Nov 2020 08:54:27 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 923222075A Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=telegraphics.com.au Authentication-Results: mail.kernel.org; spf=tempfail smtp.mailfrom=dm-devel-bounces@redhat.com Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-222-Qf5QzKrxO86so7wne6LO-g-1; Tue, 24 Nov 2020 03:54:24 -0500 X-MC-Unique: Qf5QzKrxO86so7wne6LO-g-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 9B66218C43CD; Tue, 24 Nov 2020 08:54:20 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 7912C5D71D; Tue, 24 Nov 2020 08:54:20 +0000 (UTC) Received: from lists01.pubmisc.prod.ext.phx2.redhat.com (lists01.pubmisc.prod.ext.phx2.redhat.com [10.5.19.33]) by colo-mx.corp.redhat.com (Postfix) with ESMTP id F35A54EBC6; Tue, 24 Nov 2020 08:54:19 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id 0AO0wnnM019827 for ; Mon, 23 Nov 2020 19:58:49 -0500 Received: by smtp.corp.redhat.com (Postfix) id 44E882166B2B; Tue, 24 Nov 2020 00:58:49 +0000 (UTC) Received: from mimecast-mx02.redhat.com (mimecast04.extmail.prod.ext.rdu2.redhat.com [10.11.55.20]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 3FCAC2166B27 for ; Tue, 24 Nov 2020 00:58:46 +0000 (UTC) Received: from us-smtp-1.mimecast.com (us-smtp-2.mimecast.com [207.211.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id D07F1103B801 for ; Tue, 24 Nov 2020 00:58:46 +0000 (UTC) Received: from kvm5.telegraphics.com.au (kvm5.telegraphics.com.au [98.124.60.144]) by relay.mimecast.com with ESMTP id us-mta-215-BQ-cNCnDOPiHZ0YxA-wtHg-1; Mon, 23 Nov 2020 19:58:43 -0500 X-MC-Unique: BQ-cNCnDOPiHZ0YxA-wtHg-1 Received: from localhost (localhost.localdomain [127.0.0.1]) by kvm5.telegraphics.com.au (Postfix) with ESMTP id 0EF842A8E0; Mon, 23 Nov 2020 19:58:39 -0500 (EST) Date: Tue, 24 Nov 2020 11:58:37 +1100 (AEDT) From: Finn Thain To: Miguel Ojeda In-Reply-To: Message-ID: References: <20201120105344.4345c14e@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <202011201129.B13FDB3C@keescook> <20201120115142.292999b2@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <202011220816.8B6591A@keescook> <9b57fd4914b46f38d54087d75e072d6e947cb56d.camel@HansenPartnership.com> MIME-Version: 1.0 X-Mimecast-Impersonation-Protect: Policy=CLT - Impersonation Protection Definition; Similar Internal Domain=false; Similar Monitored External Domain=false; Custom External Domain=false; Mimecast External Domain=false; Newly Observed Domain=false; Internal User Name=false; Custom Display Name List=false; Reply-to Address Mismatch=false; Targeted Threat Dictionary=false; Mimecast Threat Dictionary=false; Custom Threat Dictionary=false X-Scanned-By: MIMEDefang 2.78 on 10.11.54.6 X-loop: dm-devel@redhat.com X-Mailman-Approved-At: Tue, 24 Nov 2020 03:53:49 -0500 Cc: alsa-devel@alsa-project.org, linux-atm-general@lists.sourceforge.net, reiserfs-devel@vger.kernel.org, nouveau@lists.freedesktop.org, linux-iio@vger.kernel.org, linux-wireless , linux-fbdev@vger.kernel.org, dri-devel@lists.freedesktop.org, "Gustavo A. R. Silva" , James Bottomley , linux-ide@vger.kernel.org, dm-devel@redhat.com, keyrings@vger.kernel.org, linux-mtd@lists.infradead.org, GR-everest-linux-l2@marvell.com, wcn36xx@lists.infradead.org, samba-technical@lists.samba.org, linux-i3c@lists.infradead.org, linux1394-devel@lists.sourceforge.net, linux-afs@lists.infradead.org, usb-storage@lists.one-eyed-alien.net, linux-watchdog@vger.kernel.org, devel@driverdev.osuosl.org, linux-cifs@vger.kernel.org, rds-devel@oss.oracle.com, Nick Desaulniers , linux-scsi@vger.kernel.org, Nathan Chancellor , linux-rdma@vger.kernel.org, oss-drivers@netronome.com, bridge@lists.linux-foundation.org, linux-security-module@vger.kernel.org, amd-gfx@lists.freedesktop.org, linux-stm32@st-md-mailman.stormreply.com, cluster-devel@redhat.com, linux-acpi@vger.kernel.org, coreteam@netfilter.org, intel-wired-lan@lists.osuosl.org, linux-input , Miguel Ojeda , Jakub Kicinski , Ext4 Developers List , Linux Media Mailing List , Kees Cook , selinux@vger.kernel.org, linux-arm-msm@vger.kernel.org, intel-gfx@lists.freedesktop.org, linux-geode@lists.infradead.org, linux-can@vger.kernel.org, linux-block@vger.kernel.org, linux-gpio@vger.kernel.org, op-tee@lists.trustedfirmware.org, linux-mediatek@lists.infradead.org, xen-devel@lists.xenproject.org, drbd-dev@tron.linbit.com, linux-hams@vger.kernel.org, ceph-devel@vger.kernel.org, virtualization@lists.linux-foundation.org, target-devel@vger.kernel.org, Linux ARM , linux-hwmon@vger.kernel.org, "maintainer:X86 ARCHITECTURE \(32-BIT AND 64-BIT\)" , linux-nfs@vger.kernel.org, GR-Linux-NIC-Dev@marvell.com, tipc-discussion@lists.sourceforge.net, Linux-MM , Network Development , linux-decnet-user@lists.sourceforge.net, linux-mmc@vger.kernel.org, linux-kernel , linux-renesas-soc@vger.kernel.org, linux-sctp@vger.kernel.org, linux-usb@vger.kernel.org, netfilter-devel@vger.kernel.org, Linux Crypto Mailing List , patches@opensource.cirrus.com, Joe Perches , linux-integrity@vger.kernel.org, linux-hardening@vger.kernel.org Subject: Re: [dm-devel] [PATCH 000/141] Fix fall-through warnings for Clang X-BeenThere: dm-devel@redhat.com X-Mailman-Version: 2.1.12 Precedence: junk List-Id: device-mapper development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=dm-devel-bounces@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Mon, 23 Nov 2020, Miguel Ojeda wrote: > On Mon, 23 Nov 2020, Finn Thain wrote: > > > On Sun, 22 Nov 2020, Miguel Ojeda wrote: > > > > > > > > It isn't that much effort, isn't it? Plus we need to take into > > > account the future mistakes that it might prevent, too. > > > > We should also take into account optimisim about future improvements > > in tooling. > > > Not sure what you mean here. There is no reliable way to guess what the > intention was with a missing fallthrough, even if you parsed whitespace > and indentation. > What I meant was that you've used pessimism as if it was 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". Moreover, what I meant was that preventing programmer mistakes is a problem to be solved by development tools. The idea that retro-fitting new language constructs onto mature code is somehow necessary to "prevent future mistakes" is entirely questionable. > > > So even if there were zero problems found so far, it is still a > > > positive change. > > > > > > > It is if you want to spin it that way. > > > How is that a "spin"? It is a fact that we won't get *implicit* > fallthrough mistakes anymore (in particular if we make it a hard error). > Perhaps "handwaving" is a better term? > > > I would agree if these changes were high risk, though; but they are > > > almost trivial. > > > > > > > This is trivial: > > > > case 1: > > this(); > > + fallthrough; > > case 2: > > that(); > > > > But what we inevitably get is changes like this: > > > > case 3: > > this(); > > + break; > > case 4: > > hmmm(); > > > > Why? Mainly to silence the compiler. Also because the patch author > > argued successfully that they had found a theoretical bug, often in > > mature code. > > > If someone changes control flow, that is on them. Every kernel developer > knows what `break` does. > 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. Have you ever considered the overall cost of the countless -Wpresume-incompetence flags? 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. > > But is anyone keeping score of the regressions? If unreported bugs > > count, what about unreported regressions? > > > Introducing `fallthrough` does not change semantics. If you are really > keen, you can always compare the objects because the generated code > shouldn't change. > 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. > Cheers, > Miguel > -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DBA51C6379D for ; Tue, 24 Nov 2020 18:59:20 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 50614204FD for ; Tue, 24 Nov 2020 18:59:20 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 50614204FD Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=telegraphics.com.au Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=intel-gfx-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id D55506E514; Tue, 24 Nov 2020 18:59:14 +0000 (UTC) Received: from kvm5.telegraphics.com.au (kvm5.telegraphics.com.au [98.124.60.144]) by gabe.freedesktop.org (Postfix) with ESMTP id A5D506E162; Tue, 24 Nov 2020 00:58:45 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by kvm5.telegraphics.com.au (Postfix) with ESMTP id 0EF842A8E0; Mon, 23 Nov 2020 19:58:39 -0500 (EST) Date: Tue, 24 Nov 2020 11:58:37 +1100 (AEDT) From: Finn Thain To: Miguel Ojeda In-Reply-To: Message-ID: References: <20201120105344.4345c14e@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <202011201129.B13FDB3C@keescook> <20201120115142.292999b2@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <202011220816.8B6591A@keescook> <9b57fd4914b46f38d54087d75e072d6e947cb56d.camel@HansenPartnership.com> MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 24 Nov 2020 18:59:06 +0000 Subject: Re: [Intel-gfx] [PATCH 000/141] Fix fall-through warnings for Clang X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: alsa-devel@alsa-project.org, linux-atm-general@lists.sourceforge.net, reiserfs-devel@vger.kernel.org, linux-iio@vger.kernel.org, linux-wireless , linux-fbdev@vger.kernel.org, dri-devel@lists.freedesktop.org, "Gustavo A. R. Silva" , James Bottomley , linux-ide@vger.kernel.org, dm-devel@redhat.com, keyrings@vger.kernel.org, linux-mtd@lists.infradead.org, GR-everest-linux-l2@marvell.com, wcn36xx@lists.infradead.org, samba-technical@lists.samba.org, linux-i3c@lists.infradead.org, linux1394-devel@lists.sourceforge.net, linux-afs@lists.infradead.org, usb-storage@lists.one-eyed-alien.net, drbd-dev@lists.linbit.com, devel@driverdev.osuosl.org, linux-cifs@vger.kernel.org, rds-devel@oss.oracle.com, Nick Desaulniers , linux-scsi@vger.kernel.org, Nathan Chancellor , linux-rdma@vger.kernel.org, oss-drivers@netronome.com, bridge@lists.linux-foundation.org, linux-security-module@vger.kernel.org, amd-gfx@lists.freedesktop.org, linux-stm32@st-md-mailman.stormreply.com, cluster-devel@redhat.com, linux-acpi@vger.kernel.org, coreteam@netfilter.org, intel-wired-lan@lists.osuosl.org, linux-input , Miguel Ojeda , Jakub Kicinski , Ext4 Developers List , Linux Media Mailing List , Kees Cook , selinux@vger.kernel.org, linux-arm-msm@vger.kernel.org, intel-gfx@lists.freedesktop.org, linux-geode@lists.infradead.org, linux-can@vger.kernel.org, linux-block@vger.kernel.org, linux-gpio@vger.kernel.org, op-tee@lists.trustedfirmware.org, linux-mediatek@lists.infradead.org, xen-devel@lists.xenproject.org, nouveau@lists.freedesktop.org, linux-hams@vger.kernel.org, ceph-devel@vger.kernel.org, virtualization@lists.linux-foundation.org, target-devel@vger.kernel.org, Linux ARM , linux-hwmon@vger.kernel.org, linux-watchdog@vger.kernel.org, linux-nfs@vger.kernel.org, GR-Linux-NIC-Dev@marvell.com, tipc-discussion@lists.sourceforge.net, Linux-MM , Network Development , linux-decnet-user@lists.sourceforge.net, linux-mmc@vger.kernel.org, linux-kernel , linux-renesas-soc@vger.kernel.org, linux-sctp@vger.kernel.org, linux-usb@vger.kernel.org, netfilter-devel@vger.kernel.org, Linux Crypto Mailing List , patches@opensource.cirrus.com, Joe Perches , linux-integrity@vger.kernel.org, "maintainer:X86 ARCHITECTURE \(32-BIT AND 64-BIT\)" , linux-hardening@vger.kernel.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" On Mon, 23 Nov 2020, Miguel Ojeda wrote: > On Mon, 23 Nov 2020, Finn Thain wrote: > > > On Sun, 22 Nov 2020, Miguel Ojeda wrote: > > > > > > > > It isn't that much effort, isn't it? Plus we need to take into > > > account the future mistakes that it might prevent, too. > > > > We should also take into account optimisim about future improvements > > in tooling. > > > Not sure what you mean here. There is no reliable way to guess what the > intention was with a missing fallthrough, even if you parsed whitespace > and indentation. > What I meant was that you've used pessimism as if it was 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". Moreover, what I meant was that preventing programmer mistakes is a problem to be solved by development tools. The idea that retro-fitting new language constructs onto mature code is somehow necessary to "prevent future mistakes" is entirely questionable. > > > So even if there were zero problems found so far, it is still a > > > positive change. > > > > > > > It is if you want to spin it that way. > > > How is that a "spin"? It is a fact that we won't get *implicit* > fallthrough mistakes anymore (in particular if we make it a hard error). > Perhaps "handwaving" is a better term? > > > I would agree if these changes were high risk, though; but they are > > > almost trivial. > > > > > > > This is trivial: > > > > case 1: > > this(); > > + fallthrough; > > case 2: > > that(); > > > > But what we inevitably get is changes like this: > > > > case 3: > > this(); > > + break; > > case 4: > > hmmm(); > > > > Why? Mainly to silence the compiler. Also because the patch author > > argued successfully that they had found a theoretical bug, often in > > mature code. > > > If someone changes control flow, that is on them. Every kernel developer > knows what `break` does. > 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. Have you ever considered the overall cost of the countless -Wpresume-incompetence flags? 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. > > But is anyone keeping score of the regressions? If unreported bugs > > count, what about unreported regressions? > > > Introducing `fallthrough` does not change semantics. If you are really > keen, you can always compare the objects because the generated code > shouldn't change. > 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. > Cheers, > Miguel > _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A89AFC56201 for ; Tue, 24 Nov 2020 08:16:39 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 36C5B206E0 for ; Tue, 24 Nov 2020 08:16:39 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 36C5B206E0 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=telegraphics.com.au Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=amd-gfx-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 7BC8F6E2B8; Tue, 24 Nov 2020 08:16:36 +0000 (UTC) Received: from kvm5.telegraphics.com.au (kvm5.telegraphics.com.au [98.124.60.144]) by gabe.freedesktop.org (Postfix) with ESMTP id A5D506E162; Tue, 24 Nov 2020 00:58:45 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by kvm5.telegraphics.com.au (Postfix) with ESMTP id 0EF842A8E0; Mon, 23 Nov 2020 19:58:39 -0500 (EST) Date: Tue, 24 Nov 2020 11:58:37 +1100 (AEDT) From: Finn Thain To: Miguel Ojeda Subject: Re: [PATCH 000/141] Fix fall-through warnings for Clang In-Reply-To: Message-ID: References: <20201120105344.4345c14e@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <202011201129.B13FDB3C@keescook> <20201120115142.292999b2@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <202011220816.8B6591A@keescook> <9b57fd4914b46f38d54087d75e072d6e947cb56d.camel@HansenPartnership.com> MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 24 Nov 2020 08:16:35 +0000 X-BeenThere: amd-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion list for AMD gfx List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: alsa-devel@alsa-project.org, linux-atm-general@lists.sourceforge.net, reiserfs-devel@vger.kernel.org, linux-iio@vger.kernel.org, linux-wireless , linux-fbdev@vger.kernel.org, dri-devel@lists.freedesktop.org, "Gustavo A. R. Silva" , James Bottomley , linux-ide@vger.kernel.org, dm-devel@redhat.com, keyrings@vger.kernel.org, linux-mtd@lists.infradead.org, GR-everest-linux-l2@marvell.com, wcn36xx@lists.infradead.org, samba-technical@lists.samba.org, linux-i3c@lists.infradead.org, linux1394-devel@lists.sourceforge.net, linux-afs@lists.infradead.org, usb-storage@lists.one-eyed-alien.net, drbd-dev@lists.linbit.com, devel@driverdev.osuosl.org, linux-cifs@vger.kernel.org, rds-devel@oss.oracle.com, Nick Desaulniers , linux-scsi@vger.kernel.org, Nathan Chancellor , linux-rdma@vger.kernel.org, oss-drivers@netronome.com, bridge@lists.linux-foundation.org, linux-security-module@vger.kernel.org, amd-gfx@lists.freedesktop.org, linux-stm32@st-md-mailman.stormreply.com, cluster-devel@redhat.com, linux-acpi@vger.kernel.org, coreteam@netfilter.org, intel-wired-lan@lists.osuosl.org, linux-input , Miguel Ojeda , Jakub Kicinski , Ext4 Developers List , Linux Media Mailing List , Kees Cook , selinux@vger.kernel.org, linux-arm-msm@vger.kernel.org, intel-gfx@lists.freedesktop.org, linux-geode@lists.infradead.org, linux-can@vger.kernel.org, linux-block@vger.kernel.org, linux-gpio@vger.kernel.org, op-tee@lists.trustedfirmware.org, linux-mediatek@lists.infradead.org, xen-devel@lists.xenproject.org, nouveau@lists.freedesktop.org, linux-hams@vger.kernel.org, ceph-devel@vger.kernel.org, virtualization@lists.linux-foundation.org, target-devel@vger.kernel.org, Linux ARM , linux-hwmon@vger.kernel.org, linux-watchdog@vger.kernel.org, linux-nfs@vger.kernel.org, GR-Linux-NIC-Dev@marvell.com, tipc-discussion@lists.sourceforge.net, Linux-MM , Network Development , linux-decnet-user@lists.sourceforge.net, linux-mmc@vger.kernel.org, linux-kernel , linux-renesas-soc@vger.kernel.org, linux-sctp@vger.kernel.org, linux-usb@vger.kernel.org, netfilter-devel@vger.kernel.org, Linux Crypto Mailing List , patches@opensource.cirrus.com, Joe Perches , linux-integrity@vger.kernel.org, "maintainer:X86 ARCHITECTURE \(32-BIT AND 64-BIT\)" , linux-hardening@vger.kernel.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: amd-gfx-bounces@lists.freedesktop.org Sender: "amd-gfx" On Mon, 23 Nov 2020, Miguel Ojeda wrote: > On Mon, 23 Nov 2020, Finn Thain wrote: > > > On Sun, 22 Nov 2020, Miguel Ojeda wrote: > > > > > > > > It isn't that much effort, isn't it? Plus we need to take into > > > account the future mistakes that it might prevent, too. > > > > We should also take into account optimisim about future improvements > > in tooling. > > > Not sure what you mean here. There is no reliable way to guess what the > intention was with a missing fallthrough, even if you parsed whitespace > and indentation. > What I meant was that you've used pessimism as if it was 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". Moreover, what I meant was that preventing programmer mistakes is a problem to be solved by development tools. The idea that retro-fitting new language constructs onto mature code is somehow necessary to "prevent future mistakes" is entirely questionable. > > > So even if there were zero problems found so far, it is still a > > > positive change. > > > > > > > It is if you want to spin it that way. > > > How is that a "spin"? It is a fact that we won't get *implicit* > fallthrough mistakes anymore (in particular if we make it a hard error). > Perhaps "handwaving" is a better term? > > > I would agree if these changes were high risk, though; but they are > > > almost trivial. > > > > > > > This is trivial: > > > > case 1: > > this(); > > + fallthrough; > > case 2: > > that(); > > > > But what we inevitably get is changes like this: > > > > case 3: > > this(); > > + break; > > case 4: > > hmmm(); > > > > Why? Mainly to silence the compiler. Also because the patch author > > argued successfully that they had found a theoretical bug, often in > > mature code. > > > If someone changes control flow, that is on them. Every kernel developer > knows what `break` does. > 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. Have you ever considered the overall cost of the countless -Wpresume-incompetence flags? 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. > > But is anyone keeping score of the regressions? If unreported bugs > > count, what about unreported regressions? > > > Introducing `fallthrough` does not change semantics. If you are really > keen, you can always compare the objects because the generated code > shouldn't change. > 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. > Cheers, > Miguel > _______________________________________________ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 57F96C5519F for ; Wed, 25 Nov 2020 09:57:25 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id C8D6C206B7 for ; Wed, 25 Nov 2020 09:57:24 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="uIB0lem0" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C8D6C206B7 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=telegraphics.com.au Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-i3c-bounces+linux-i3c=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:MIME-Version:References:Message-ID:In-Reply-To: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=B9K2L2cZtFfTdnmfwVCw0aIjArzNfP2xAFapXf2pZLs=; b=uIB0lem0TQgcEFgjLfm75Tlau CnZcdM4gmkS4HKRGrZP/AlWJiO9axkt4JwOM2UXxIDJYg4gO0S0CKBZ3gL2uxin2AOYXGHJmllJwI OnPtzhBtdeF/afptI9GJw3bTdQGZKkEn0WEqAvUo0Pu6FAKYn8TpJEksY03lF6FFtWMyEtJRP5xjK Ev3heGw7PRfruv20n8B+G5T/md33zROXPiFRmoDArpDWagxiDjfWZAlV682Ym/l4En7pLnwP0FpT9 i0nrcY2s9H9wVX/sBFC2MxDcKPZFiN7ouewmNq6SLz8AHYY6h93AvdWaBzGykN3TZJ2UDYchBNdRw BbWZCgpPQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1khrYB-0006Y5-Vk; Wed, 25 Nov 2020 09:57:24 +0000 Received: from kvm5.telegraphics.com.au ([98.124.60.144]) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1khMfO-0004uH-Hs; Tue, 24 Nov 2020 00:58:47 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by kvm5.telegraphics.com.au (Postfix) with ESMTP id 0EF842A8E0; Mon, 23 Nov 2020 19:58:39 -0500 (EST) Date: Tue, 24 Nov 2020 11:58:37 +1100 (AEDT) From: Finn Thain To: Miguel Ojeda Subject: Re: [PATCH 000/141] Fix fall-through warnings for Clang In-Reply-To: Message-ID: References: <20201120105344.4345c14e@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <202011201129.B13FDB3C@keescook> <20201120115142.292999b2@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <202011220816.8B6591A@keescook> <9b57fd4914b46f38d54087d75e072d6e947cb56d.camel@HansenPartnership.com> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201123_195846_722086_ED051A37 X-CRM114-Status: GOOD ( 25.82 ) X-Mailman-Approved-At: Wed, 25 Nov 2020 04:56:59 -0500 X-BeenThere: linux-i3c@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: alsa-devel@alsa-project.org, linux-atm-general@lists.sourceforge.net, reiserfs-devel@vger.kernel.org, linux-iio@vger.kernel.org, linux-wireless , linux-fbdev@vger.kernel.org, dri-devel@lists.freedesktop.org, "Gustavo A. R. Silva" , James Bottomley , linux-ide@vger.kernel.org, dm-devel@redhat.com, keyrings@vger.kernel.org, linux-mtd@lists.infradead.org, GR-everest-linux-l2@marvell.com, wcn36xx@lists.infradead.org, samba-technical@lists.samba.org, linux-i3c@lists.infradead.org, linux1394-devel@lists.sourceforge.net, linux-afs@lists.infradead.org, usb-storage@lists.one-eyed-alien.net, drbd-dev@lists.linbit.com, devel@driverdev.osuosl.org, linux-cifs@vger.kernel.org, rds-devel@oss.oracle.com, Nick Desaulniers , linux-scsi@vger.kernel.org, Nathan Chancellor , linux-rdma@vger.kernel.org, oss-drivers@netronome.com, bridge@lists.linux-foundation.org, linux-security-module@vger.kernel.org, amd-gfx@lists.freedesktop.org, linux-stm32@st-md-mailman.stormreply.com, cluster-devel@redhat.com, linux-acpi@vger.kernel.org, coreteam@netfilter.org, intel-wired-lan@lists.osuosl.org, linux-input , Miguel Ojeda , Jakub Kicinski , Ext4 Developers List , Linux Media Mailing List , Kees Cook , selinux@vger.kernel.org, linux-arm-msm@vger.kernel.org, intel-gfx@lists.freedesktop.org, linux-geode@lists.infradead.org, linux-can@vger.kernel.org, linux-block@vger.kernel.org, linux-gpio@vger.kernel.org, op-tee@lists.trustedfirmware.org, linux-mediatek@lists.infradead.org, xen-devel@lists.xenproject.org, nouveau@lists.freedesktop.org, linux-hams@vger.kernel.org, ceph-devel@vger.kernel.org, virtualization@lists.linux-foundation.org, Linux ARM , linux-hwmon@vger.kernel.org, linux-watchdog@vger.kernel.org, linux-nfs@vger.kernel.org, GR-Linux-NIC-Dev@marvell.com, tipc-discussion@lists.sourceforge.net, Linux-MM , Network Development , linux-decnet-user@lists.sourceforge.net, linux-mmc@vger.kernel.org, linux-kernel , "maintainer:X86 ARCHITECTURE \(32-BIT AND 64-BIT\)" , linux-renesas-soc@vger.kernel.org, linux-sctp@vger.kernel.org, linux-usb@vger.kernel.org, netfilter-devel@vger.kernel.org, Linux Crypto Mailing List , patches@opensource.cirrus.com, Joe Perches , linux-integrity@vger.kernel.org, target-devel@vger.kernel.org, linux-hardening@vger.kernel.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-i3c" Errors-To: linux-i3c-bounces+linux-i3c=archiver.kernel.org@lists.infradead.org On Mon, 23 Nov 2020, Miguel Ojeda wrote: > On Mon, 23 Nov 2020, Finn Thain wrote: > > > On Sun, 22 Nov 2020, Miguel Ojeda wrote: > > > > > > > > It isn't that much effort, isn't it? Plus we need to take into > > > account the future mistakes that it might prevent, too. > > > > We should also take into account optimisim about future improvements > > in tooling. > > > Not sure what you mean here. There is no reliable way to guess what the > intention was with a missing fallthrough, even if you parsed whitespace > and indentation. > What I meant was that you've used pessimism as if it was 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". Moreover, what I meant was that preventing programmer mistakes is a problem to be solved by development tools. The idea that retro-fitting new language constructs onto mature code is somehow necessary to "prevent future mistakes" is entirely questionable. > > > So even if there were zero problems found so far, it is still a > > > positive change. > > > > > > > It is if you want to spin it that way. > > > How is that a "spin"? It is a fact that we won't get *implicit* > fallthrough mistakes anymore (in particular if we make it a hard error). > Perhaps "handwaving" is a better term? > > > I would agree if these changes were high risk, though; but they are > > > almost trivial. > > > > > > > This is trivial: > > > > case 1: > > this(); > > + fallthrough; > > case 2: > > that(); > > > > But what we inevitably get is changes like this: > > > > case 3: > > this(); > > + break; > > case 4: > > hmmm(); > > > > Why? Mainly to silence the compiler. Also because the patch author > > argued successfully that they had found a theoretical bug, often in > > mature code. > > > If someone changes control flow, that is on them. Every kernel developer > knows what `break` does. > 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. Have you ever considered the overall cost of the countless -Wpresume-incompetence flags? 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. > > But is anyone keeping score of the regressions? If unreported bugs > > count, what about unreported regressions? > > > Introducing `fallthrough` does not change semantics. If you are really > keen, you can always compare the objects because the generated code > shouldn't change. > 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. > Cheers, > Miguel > -- linux-i3c mailing list linux-i3c@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-i3c From mboxrd@z Thu Jan 1 00:00:00 1970 From: Finn Thain Date: Tue, 24 Nov 2020 11:58:37 +1100 (AEDT) Subject: [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang In-Reply-To: References: <20201120105344.4345c14e@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <202011201129.B13FDB3C@keescook> <20201120115142.292999b2@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <202011220816.8B6591A@keescook> <9b57fd4914b46f38d54087d75e072d6e947cb56d.camel@HansenPartnership.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: intel-wired-lan@osuosl.org List-ID: On Mon, 23 Nov 2020, Miguel Ojeda wrote: > On Mon, 23 Nov 2020, Finn Thain wrote: > > > On Sun, 22 Nov 2020, Miguel Ojeda wrote: > > > > > > > > It isn't that much effort, isn't it? Plus we need to take into > > > account the future mistakes that it might prevent, too. > > > > We should also take into account optimisim about future improvements > > in tooling. > > > Not sure what you mean here. There is no reliable way to guess what the > intention was with a missing fallthrough, even if you parsed whitespace > and indentation. > What I meant was that you've used pessimism as if it was 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". Moreover, what I meant was that preventing programmer mistakes is a problem to be solved by development tools. The idea that retro-fitting new language constructs onto mature code is somehow necessary to "prevent future mistakes" is entirely questionable. > > > So even if there were zero problems found so far, it is still a > > > positive change. > > > > > > > It is if you want to spin it that way. > > > How is that a "spin"? It is a fact that we won't get *implicit* > fallthrough mistakes anymore (in particular if we make it a hard error). > Perhaps "handwaving" is a better term? > > > I would agree if these changes were high risk, though; but they are > > > almost trivial. > > > > > > > This is trivial: > > > > case 1: > > this(); > > + fallthrough; > > case 2: > > that(); > > > > But what we inevitably get is changes like this: > > > > case 3: > > this(); > > + break; > > case 4: > > hmmm(); > > > > Why? Mainly to silence the compiler. Also because the patch author > > argued successfully that they had found a theoretical bug, often in > > mature code. > > > If someone changes control flow, that is on them. Every kernel developer > knows what `break` does. > 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. Have you ever considered the overall cost of the countless -Wpresume-incompetence flags? 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. > > But is anyone keeping score of the regressions? If unreported bugs > > count, what about unreported regressions? > > > Introducing `fallthrough` does not change semantics. If you are really > keen, you can always compare the objects because the generated code > shouldn't change. > 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. > Cheers, > Miguel > From mboxrd@z Thu Jan 1 00:00:00 1970 From: Finn Thain Date: Tue, 24 Nov 2020 11:58:37 +1100 (AEDT) Subject: [Cluster-devel] [PATCH 000/141] Fix fall-through warnings for Clang In-Reply-To: References: <20201120105344.4345c14e@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <202011201129.B13FDB3C@keescook> <20201120115142.292999b2@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <202011220816.8B6591A@keescook> <9b57fd4914b46f38d54087d75e072d6e947cb56d.camel@HansenPartnership.com> Message-ID: List-Id: To: cluster-devel.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Mon, 23 Nov 2020, Miguel Ojeda wrote: > On Mon, 23 Nov 2020, Finn Thain wrote: > > > On Sun, 22 Nov 2020, Miguel Ojeda wrote: > > > > > > > > It isn't that much effort, isn't it? Plus we need to take into > > > account the future mistakes that it might prevent, too. > > > > We should also take into account optimisim about future improvements > > in tooling. > > > Not sure what you mean here. There is no reliable way to guess what the > intention was with a missing fallthrough, even if you parsed whitespace > and indentation. > What I meant was that you've used pessimism as if it was 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". Moreover, what I meant was that preventing programmer mistakes is a problem to be solved by development tools. The idea that retro-fitting new language constructs onto mature code is somehow necessary to "prevent future mistakes" is entirely questionable. > > > So even if there were zero problems found so far, it is still a > > > positive change. > > > > > > > It is if you want to spin it that way. > > > How is that a "spin"? It is a fact that we won't get *implicit* > fallthrough mistakes anymore (in particular if we make it a hard error). > Perhaps "handwaving" is a better term? > > > I would agree if these changes were high risk, though; but they are > > > almost trivial. > > > > > > > This is trivial: > > > > case 1: > > this(); > > + fallthrough; > > case 2: > > that(); > > > > But what we inevitably get is changes like this: > > > > case 3: > > this(); > > + break; > > case 4: > > hmmm(); > > > > Why? Mainly to silence the compiler. Also because the patch author > > argued successfully that they had found a theoretical bug, often in > > mature code. > > > If someone changes control flow, that is on them. Every kernel developer > knows what `break` does. > 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. Have you ever considered the overall cost of the countless -Wpresume-incompetence flags? 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. > > But is anyone keeping score of the regressions? If unreported bugs > > count, what about unreported regressions? > > > Introducing `fallthrough` does not change semantics. If you are really > keen, you can always compare the objects because the generated code > shouldn't change. > 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. > Cheers, > Miguel > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Tue, 24 Nov 2020 11:58:37 +1100 (AEDT) From: Finn Thain In-Reply-To: Message-ID: References: <20201120105344.4345c14e@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <202011201129.B13FDB3C@keescook> <20201120115142.292999b2@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <202011220816.8B6591A@keescook> <9b57fd4914b46f38d54087d75e072d6e947cb56d.camel@HansenPartnership.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Subject: Re: [Bridge] [PATCH 000/141] Fix fall-through warnings for Clang List-Id: Linux Ethernet Bridging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Miguel Ojeda Cc: alsa-devel@alsa-project.org, linux-atm-general@lists.sourceforge.net, reiserfs-devel@vger.kernel.org, linux-iio@vger.kernel.org, linux-wireless , linux-fbdev@vger.kernel.org, dri-devel@lists.freedesktop.org, "Gustavo A. R. Silva" , James Bottomley , linux-ide@vger.kernel.org, dm-devel@redhat.com, keyrings@vger.kernel.org, linux-mtd@lists.infradead.org, GR-everest-linux-l2@marvell.com, wcn36xx@lists.infradead.org, samba-technical@lists.samba.org, linux-i3c@lists.infradead.org, linux1394-devel@lists.sourceforge.net, linux-afs@lists.infradead.org, usb-storage@lists.one-eyed-alien.net, drbd-dev@lists.linbit.com, devel@driverdev.osuosl.org, linux-cifs@vger.kernel.org, rds-devel@oss.oracle.com, Nick Desaulniers , linux-scsi@vger.kernel.org, Nathan Chancellor , linux-rdma@vger.kernel.org, oss-drivers@netronome.com, bridge@lists.linux-foundation.org, linux-security-module@vger.kernel.org, amd-gfx@lists.freedesktop.org, linux-stm32@st-md-mailman.stormreply.com, cluster-devel@redhat.com, linux-acpi@vger.kernel.org, coreteam@netfilter.org, intel-wired-lan@lists.osuosl.org, linux-input , Miguel Ojeda , Jakub Kicinski , Ext4 Developers List , Linux Media Mailing List , Kees Cook , selinux@vger.kernel.org, linux-arm-msm@vger.kernel.org, intel-gfx@lists.freedesktop.org, linux-geode@lists.infradead.org, linux-can@vger.kernel.org, linux-block@vger.kernel.org, linux-gpio@vger.kernel.org, op-tee@lists.trustedfirmware.org, linux-mediatek@lists.infradead.org, xen-devel@lists.xenproject.org, nouveau@lists.freedesktop.org, linux-hams@vger.kernel.org, ceph-devel@vger.kernel.org, virtualization@lists.linux-foundation.org, Linux ARM , linux-hwmon@vger.kernel.org, linux-watchdog@vger.kernel.org, linux-nfs@vger.kernel.org, GR-Linux-NIC-Dev@marvell.com, tipc-discussion@lists.sourceforge.net, Linux-MM , Network Development , linux-decnet-user@lists.sourceforge.net, linux-mmc@vger.kernel.org, linux-kernel , "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" , linux-renesas-soc@vger.kernel.org, linux-sctp@vger.kernel.org, linux-usb@vger.kernel.org, netfilter-devel@vger.kernel.org, Linux Crypto Mailing List , patches@opensource.cirrus.com, Joe Perches , linux-integrity@vger.kernel.org, target-devel@vger.kernel.org, linux-hardening@vger.kernel.org On Mon, 23 Nov 2020, Miguel Ojeda wrote: > On Mon, 23 Nov 2020, Finn Thain wrote: > > > On Sun, 22 Nov 2020, Miguel Ojeda wrote: > > > > > > > > It isn't that much effort, isn't it? Plus we need to take into > > > account the future mistakes that it might prevent, too. > > > > We should also take into account optimisim about future improvements > > in tooling. > > > Not sure what you mean here. There is no reliable way to guess what the > intention was with a missing fallthrough, even if you parsed whitespace > and indentation. > What I meant was that you've used pessimism as if it was 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". Moreover, what I meant was that preventing programmer mistakes is a problem to be solved by development tools. The idea that retro-fitting new language constructs onto mature code is somehow necessary to "prevent future mistakes" is entirely questionable. > > > So even if there were zero problems found so far, it is still a > > > positive change. > > > > > > > It is if you want to spin it that way. > > > How is that a "spin"? It is a fact that we won't get *implicit* > fallthrough mistakes anymore (in particular if we make it a hard error). > Perhaps "handwaving" is a better term? > > > I would agree if these changes were high risk, though; but they are > > > almost trivial. > > > > > > > This is trivial: > > > > case 1: > > this(); > > + fallthrough; > > case 2: > > that(); > > > > But what we inevitably get is changes like this: > > > > case 3: > > this(); > > + break; > > case 4: > > hmmm(); > > > > Why? Mainly to silence the compiler. Also because the patch author > > argued successfully that they had found a theoretical bug, often in > > mature code. > > > If someone changes control flow, that is on them. Every kernel developer > knows what `break` does. > 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. Have you ever considered the overall cost of the countless -Wpresume-incompetence flags? 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. > > But is anyone keeping score of the regressions? If unreported bugs > > count, what about unreported regressions? > > > Introducing `fallthrough` does not change semantics. If you are really > keen, you can always compare the objects because the generated code > shouldn't change. > 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. > Cheers, > Miguel >