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=-2.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, 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 0A5B0C83019 for ; Tue, 24 Nov 2020 23:47:03 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id BCBE321734 for ; Tue, 24 Nov 2020 23:47:02 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="rGjC6KnG" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2389360AbgKXXqg (ORCPT ); Tue, 24 Nov 2020 18:46:36 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45038 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2389335AbgKXXqf (ORCPT ); Tue, 24 Nov 2020 18:46:35 -0500 Received: from mail-qk1-x743.google.com (mail-qk1-x743.google.com [IPv6:2607:f8b0:4864:20::743]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 16AEFC061A4D; Tue, 24 Nov 2020 15:46:35 -0800 (PST) Received: by mail-qk1-x743.google.com with SMTP id z188so1152965qke.9; Tue, 24 Nov 2020 15:46:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=H+rGPaoJ9R3rr7zK4cuxMwlBlLpdlGUAwlQnvIZjZd8=; b=rGjC6KnGzC9NIfLo6IfoTM7C5TiZmv4q08vYNRt8cewMWpFhbX886WW47/gIiopas/ e2jKhT73QJs/dRAIbILcJdQSFnVW9dal1rOBoIKd0ECBe+nqcukIgJrBRfX2wbZlPbrR 27L+0GE9CXpbAta7TZEIdoDweQHp+sEvmypYMH9hyutdrnRkkklGbspFfFiZY+HYfDHj jsH/8tjPy+0JiTdJWitSDoQxXZntWXoEWL0cWLR+fmdpM332GBoSCjfuWUHY88IWDiPh 04ztpEPYlCjpB7IXy1yQhW/otwe7DgKcwtOpyIrk5XdAw3ZKiOAkll08YWpT8S+NhzMx e/Gw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=H+rGPaoJ9R3rr7zK4cuxMwlBlLpdlGUAwlQnvIZjZd8=; b=jxuPoDkO7k9n/MFULzedHMiJ5kYn+mbhh/W4/G11sFOKoRB8zioigX2q8my85PfEwg N5hDvTDSeWvRmVykq272uRKDWiKST142DCvr+gAPgHiKkvZj09B7RdXuJpVOoqoftQA+ vv5RtYm3oipYN7FIMs0/4pzrxht9YEdFnpF32JnCX4adm39jC18J2his7cVd5oGjSpVE dHaWYkfvN9t7FdyMsrb+sEuQ/UmSukgSfrezCFHJw3VQigZElRXeIM2yUbfGQlPyFeiR FyDR90oVw1CUvN4AiNFESRNNYBxfI7IwanFHNNAMaKSV2Bn8TbmG9Smx4jN6lP9JxvVI RJCw== X-Gm-Message-State: AOAM532aLPVq45kScnh+IcXWYbf07njZDSKlLO4SuiHlpLM0tfOR7tgp ZesaOgqpyV/BN+CjlNB6fOupfaUB+iHE18+0mMY= X-Google-Smtp-Source: ABdhPJzOwu2wFsHHn8A1YNPfZeoFLdmnMgNDFogUYxSXdSyfkKR4RJ+IXZpEdbdh4p7RHhstmUROclNZOq0Hltp8jFg= X-Received: by 2002:a5b:40e:: with SMTP id m14mr627984ybp.33.1606261594309; Tue, 24 Nov 2020 15:46:34 -0800 (PST) MIME-Version: 1.0 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> In-Reply-To: From: Miguel Ojeda Date: Wed, 25 Nov 2020 00:46:23 +0100 Message-ID: Subject: Re: [PATCH 000/141] Fix fall-through warnings for Clang To: Finn Thain 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 Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org On Tue, Nov 24, 2020 at 1:58 AM Finn Thain wrote: > > What I meant was that you've used pessimism as if it was fact. "future mistakes that it might prevent" is neither pessimism nor states a fact. > For example, "There is no way to guess what the effect would be if the > compiler trained programmers to add a knee-jerk 'break' statement to avoid > a warning". It is only knee-jerk if you think you are infallible. > Moreover, what I meant was that preventing programmer mistakes is a > problem to be solved by development tools This warning comes from a development tool -- the compiler. > The idea that retro-fitting new > language constructs onto mature code is somehow necessary to "prevent > future mistakes" is entirely questionable. The kernel is not a frozen codebase. Further, "mature code vs. risk of change" arguments don't apply here because the semantics of the program and binary output isn't changing. > Sure. And if you put -Wimplicit-fallthrough into the Makefile and if that > leads to well-intentioned patches that cause regressions, it is partly on > you. Again: adding a `fallthrough` does not change the program semantics. If you are a maintainer and want to cross-check, compare the codegen. > Have you ever considered the overall cost of the countless > -Wpresume-incompetence flags? Yeah: negative. On the other hand, the overall cost of the countless -fI-am-infallible flags is very noticeable. > Perhaps you pay the power bill for a build farm that produces logs that > no-one reads? Perhaps you've run git bisect, knowing that the compiler > messages are not interesting? Or compiled software in using a language > that generates impenetrable messages? If so, here's a tip: > > # grep CFLAGS /etc/portage/make.conf > CFLAGS="... -Wno-all -Wno-extra ..." > CXXFLAGS="${CFLAGS}" > > Now allow me some pessimism: the hardware upgrades, gigawatt hours and > wait time attributable to obligatory static analyses are a net loss. If you really believe compiler warnings and static analysis are useless and costly, I think there is not much point in continuing the discussion. > No, it's not for me to prove that such patches don't affect code > generation. That's for the patch author and (unfortunately) for reviewers. I was not asking you to prove it. I am stating that proving it is very easy. Cheers, Miguel 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=-2.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, 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 5A776C2D0E4 for ; Tue, 24 Nov 2020 23:46:37 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A74D520BED for ; Tue, 24 Nov 2020 23:46:36 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="rGjC6KnG" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A74D520BED Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id D4D316B006E; Tue, 24 Nov 2020 18:46:35 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D23616B0070; Tue, 24 Nov 2020 18:46:35 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BF4186B0071; Tue, 24 Nov 2020 18:46:35 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0078.hostedemail.com [216.40.44.78]) by kanga.kvack.org (Postfix) with ESMTP id A833F6B006E for ; Tue, 24 Nov 2020 18:46:35 -0500 (EST) Received: from smtpin26.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 70490180AD817 for ; Tue, 24 Nov 2020 23:46:35 +0000 (UTC) X-FDA: 77520948750.26.robin81_300b98c27372 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin26.hostedemail.com (Postfix) with ESMTP id 4E6C91804B66A for ; Tue, 24 Nov 2020 23:46:35 +0000 (UTC) X-HE-Tag: robin81_300b98c27372 X-Filterd-Recvd-Size: 8335 Received: from mail-qk1-f193.google.com (mail-qk1-f193.google.com [209.85.222.193]) by imf38.hostedemail.com (Postfix) with ESMTP for ; Tue, 24 Nov 2020 23:46:34 +0000 (UTC) Received: by mail-qk1-f193.google.com with SMTP id q22so1190285qkq.6 for ; Tue, 24 Nov 2020 15:46:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=H+rGPaoJ9R3rr7zK4cuxMwlBlLpdlGUAwlQnvIZjZd8=; b=rGjC6KnGzC9NIfLo6IfoTM7C5TiZmv4q08vYNRt8cewMWpFhbX886WW47/gIiopas/ e2jKhT73QJs/dRAIbILcJdQSFnVW9dal1rOBoIKd0ECBe+nqcukIgJrBRfX2wbZlPbrR 27L+0GE9CXpbAta7TZEIdoDweQHp+sEvmypYMH9hyutdrnRkkklGbspFfFiZY+HYfDHj jsH/8tjPy+0JiTdJWitSDoQxXZntWXoEWL0cWLR+fmdpM332GBoSCjfuWUHY88IWDiPh 04ztpEPYlCjpB7IXy1yQhW/otwe7DgKcwtOpyIrk5XdAw3ZKiOAkll08YWpT8S+NhzMx e/Gw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=H+rGPaoJ9R3rr7zK4cuxMwlBlLpdlGUAwlQnvIZjZd8=; b=sd5nWmw+YaM44kmHdUVFc6ognmB96YGsrnAtEhoWi5d296IjqYefeWmA4wjX3nd6Yh /0U+0N2Q2w/6WZ+GDWWVr06NA3pPCZsxi+J8aZAKrP5y1eUlFIjsiy5uXcLF9pCsjD6W g5YwwdBkcbWm3k/Q4Fh3x9v1TgCkvOs1GVTPNNVp3lWfRnMoGUbHpLDrw3auwwQ9GD7v 12vX5ehCCCxoT2BM7swEmE7MiaUUuzyg/GAAAHX2KmwUQQEUfA4VFW9P/qewErUp5lnB kAEXckozkETibBLE5YjTZBli825/JtwHHgelJArLcSeyuEgmdxkZDOK80DoH2eOHkk5x 42+A== X-Gm-Message-State: AOAM531KoS0e8ck8w1jf+0r1M50C1FPxR6Z9m8D+G1ruHIdTX6xchW3W fqToh4AD0ZVEm2MhqYiRn7bHv7u0bHkOo1nON3iJvRLCCIYiNQ== X-Google-Smtp-Source: ABdhPJzOwu2wFsHHn8A1YNPfZeoFLdmnMgNDFogUYxSXdSyfkKR4RJ+IXZpEdbdh4p7RHhstmUROclNZOq0Hltp8jFg= X-Received: by 2002:a5b:40e:: with SMTP id m14mr627984ybp.33.1606261594309; Tue, 24 Nov 2020 15:46:34 -0800 (PST) MIME-Version: 1.0 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> In-Reply-To: From: Miguel Ojeda Date: Wed, 25 Nov 2020 00:46:23 +0100 Message-ID: Subject: Re: [PATCH 000/141] Fix fall-through warnings for Clang To: Finn Thain 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 Content-Type: text/plain; charset="UTF-8" X-Bogosity: Ham, tests=bogofilter, spamicity=0.016598, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, Nov 24, 2020 at 1:58 AM Finn Thain wrote: > > What I meant was that you've used pessimism as if it was fact. "future mistakes that it might prevent" is neither pessimism nor states a fact. > For example, "There is no way to guess what the effect would be if the > compiler trained programmers to add a knee-jerk 'break' statement to avoid > a warning". It is only knee-jerk if you think you are infallible. > Moreover, what I meant was that preventing programmer mistakes is a > problem to be solved by development tools This warning comes from a development tool -- the compiler. > The idea that retro-fitting new > language constructs onto mature code is somehow necessary to "prevent > future mistakes" is entirely questionable. The kernel is not a frozen codebase. Further, "mature code vs. risk of change" arguments don't apply here because the semantics of the program and binary output isn't changing. > Sure. And if you put -Wimplicit-fallthrough into the Makefile and if that > leads to well-intentioned patches that cause regressions, it is partly on > you. Again: adding a `fallthrough` does not change the program semantics. If you are a maintainer and want to cross-check, compare the codegen. > Have you ever considered the overall cost of the countless > -Wpresume-incompetence flags? Yeah: negative. On the other hand, the overall cost of the countless -fI-am-infallible flags is very noticeable. > Perhaps you pay the power bill for a build farm that produces logs that > no-one reads? Perhaps you've run git bisect, knowing that the compiler > messages are not interesting? Or compiled software in using a language > that generates impenetrable messages? If so, here's a tip: > > # grep CFLAGS /etc/portage/make.conf > CFLAGS="... -Wno-all -Wno-extra ..." > CXXFLAGS="${CFLAGS}" > > Now allow me some pessimism: the hardware upgrades, gigawatt hours and > wait time attributable to obligatory static analyses are a net loss. If you really believe compiler warnings and static analysis are useless and costly, I think there is not much point in continuing the discussion. > No, it's not for me to prove that such patches don't affect code > generation. That's for the patch author and (unfortunately) for reviewers. I was not asking you to prove it. I am stating that proving it is very easy. Cheers, Miguel 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=-0.7 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,DKIM_VALID,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, 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 2E1E0C2D0E4 for ; Tue, 24 Nov 2020 23:47:38 +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 B74F82100A for ; Tue, 24 Nov 2020 23:47:37 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="0eqItYj8"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="rGjC6KnG" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B74F82100A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com 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:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=hfecQVDLgrMookDLE/kq5nRYMu3s6P++p/wqA22Te7s=; b=0eqItYj8nO10QptS9PwN6rVNC 2lRgineFE5tLqdvpz+1vIN8M20vPyTNsiWjT4OvE9KmJHTDjxUDKpnwMwuTID6RZQsWDkwLSSWy3o 9AdAE+3LPpACgvTheG5+OiQz2rGGmNCfOPtUMoIaeSY52bxZF9AviVkxo8aortEiQtjpK+tz55Hhx a8bG5Yy937EMal7tZWtByn8ueWAtDzxI/BZFS2K9mQyXemHoLW1qzSK9c5wuAtWl8vROU/BjO9UbS 7Zq7yy2rFpHvry1RyaWDgLdV+wubIg+S+zJdaOeOsyS4cek726EeL+3PKiNVIyakOHhvEAjEcMiUr AD315t44g==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1khi1D-0007Ii-Dc; Tue, 24 Nov 2020 23:46:43 +0000 Received: from mail-qk1-x744.google.com ([2607:f8b0:4864:20::744]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1khi16-0007Fo-9K; Tue, 24 Nov 2020 23:46:37 +0000 Received: by mail-qk1-x744.google.com with SMTP id q22so1190287qkq.6; Tue, 24 Nov 2020 15:46:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=H+rGPaoJ9R3rr7zK4cuxMwlBlLpdlGUAwlQnvIZjZd8=; b=rGjC6KnGzC9NIfLo6IfoTM7C5TiZmv4q08vYNRt8cewMWpFhbX886WW47/gIiopas/ e2jKhT73QJs/dRAIbILcJdQSFnVW9dal1rOBoIKd0ECBe+nqcukIgJrBRfX2wbZlPbrR 27L+0GE9CXpbAta7TZEIdoDweQHp+sEvmypYMH9hyutdrnRkkklGbspFfFiZY+HYfDHj jsH/8tjPy+0JiTdJWitSDoQxXZntWXoEWL0cWLR+fmdpM332GBoSCjfuWUHY88IWDiPh 04ztpEPYlCjpB7IXy1yQhW/otwe7DgKcwtOpyIrk5XdAw3ZKiOAkll08YWpT8S+NhzMx e/Gw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=H+rGPaoJ9R3rr7zK4cuxMwlBlLpdlGUAwlQnvIZjZd8=; b=TuAvjxwjT445lMd0pA19KFC41p7wFL3HpX87iRUSwYKecaY5CUfZGct0eplp4BJ0qb XiLVR9bkLwYNAqYbnPCeCrmFMmzIYCex6DLHYCnXX+zltCNsaCLpjrQx4r/2rmFuFTxp OTWYMwGItGlUPxY9pOrHKkBQk5OsO81nPbRFSRldqVfEmFEQ19oxufnBVpuizZXjTJ3J SqcHKA6zqtjv+8GF30372iB+q1pf4m1+gNSwzQ4iPc9XGNvnJVl3zD9hoBWrYyzUvJg7 rSKHNYAEM+yVkGmxnTuKXOEZmV3wJKia/q5GQqCoZRYdoET7bWZN/1p/1d5q50/73x8u UDrQ== X-Gm-Message-State: AOAM533cWSfF1GKXDPTkXDzUnQ9dFzxyHvitaynzzfrEbImfdlf5kdde /o4zLjdIUAxY8/gXzQXC0P68KCW3n/OI9g4r+DM= X-Google-Smtp-Source: ABdhPJzOwu2wFsHHn8A1YNPfZeoFLdmnMgNDFogUYxSXdSyfkKR4RJ+IXZpEdbdh4p7RHhstmUROclNZOq0Hltp8jFg= X-Received: by 2002:a5b:40e:: with SMTP id m14mr627984ybp.33.1606261594309; Tue, 24 Nov 2020 15:46:34 -0800 (PST) MIME-Version: 1.0 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> In-Reply-To: From: Miguel Ojeda Date: Wed, 25 Nov 2020 00:46:23 +0100 Message-ID: Subject: Re: [PATCH 000/141] Fix fall-through warnings for Clang To: Finn Thain X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201124_184636_515464_638921CF X-CRM114-Status: GOOD ( 20.26 ) 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 Tue, Nov 24, 2020 at 1:58 AM Finn Thain wrote: > > What I meant was that you've used pessimism as if it was fact. "future mistakes that it might prevent" is neither pessimism nor states a fact. > For example, "There is no way to guess what the effect would be if the > compiler trained programmers to add a knee-jerk 'break' statement to avoid > a warning". It is only knee-jerk if you think you are infallible. > Moreover, what I meant was that preventing programmer mistakes is a > problem to be solved by development tools This warning comes from a development tool -- the compiler. > The idea that retro-fitting new > language constructs onto mature code is somehow necessary to "prevent > future mistakes" is entirely questionable. The kernel is not a frozen codebase. Further, "mature code vs. risk of change" arguments don't apply here because the semantics of the program and binary output isn't changing. > Sure. And if you put -Wimplicit-fallthrough into the Makefile and if that > leads to well-intentioned patches that cause regressions, it is partly on > you. Again: adding a `fallthrough` does not change the program semantics. If you are a maintainer and want to cross-check, compare the codegen. > Have you ever considered the overall cost of the countless > -Wpresume-incompetence flags? Yeah: negative. On the other hand, the overall cost of the countless -fI-am-infallible flags is very noticeable. > Perhaps you pay the power bill for a build farm that produces logs that > no-one reads? Perhaps you've run git bisect, knowing that the compiler > messages are not interesting? Or compiled software in using a language > that generates impenetrable messages? If so, here's a tip: > > # grep CFLAGS /etc/portage/make.conf > CFLAGS="... -Wno-all -Wno-extra ..." > CXXFLAGS="${CFLAGS}" > > Now allow me some pessimism: the hardware upgrades, gigawatt hours and > wait time attributable to obligatory static analyses are a net loss. If you really believe compiler warnings and static analysis are useless and costly, I think there is not much point in continuing the discussion. > No, it's not for me to prove that such patches don't affect code > generation. That's for the patch author and (unfortunately) for reviewers. I was not asking you to prove it. I am stating that proving it is very easy. Cheers, Miguel ______________________________________________________ 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=-0.7 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,DKIM_VALID,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, 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 23202C2D0E4 for ; Tue, 24 Nov 2020 23:46:47 +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 5FC432100A for ; Tue, 24 Nov 2020 23:46:46 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="qc6elSX+"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="rGjC6KnG" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5FC432100A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com 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:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=lS19Mx8BP9jyKEzOssF5N+wEdkuH9ECGusV6xZ0qxw4=; b=qc6elSX+o5xMrnCW/Qheqsjxq r7RYOfwkaUOfgsJmD2NIGODaR7yXHHia2D89ftDO8Wfo8DFc9QG3j66yz20P+AIIE+FbApYmDx45u P7OzkXFeq8PLv2vFWA37Smuie7y7qA2NrryHlo7F5HNDgWe4Stqb9LEJM31PQz52EbFzzZ/dOso1c 9uWGFBat5dspbwoxQ3fVvtrXDPIV4wlN0IEhoQKfZtxvQqVzDDsptU41THd1uikJPtPr6C8OghabP 5aevjluoEZ4HHyw/ugkHgOEV+rgu110dOBnIyi7oFv1mpDSHrunhTHtI3HMU9Hb+VM311vMZ8fEhm nPYveTyeQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1khi1C-0007IH-JZ; Tue, 24 Nov 2020 23:46:42 +0000 Received: from mail-qk1-x744.google.com ([2607:f8b0:4864:20::744]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1khi16-0007Fo-9K; Tue, 24 Nov 2020 23:46:37 +0000 Received: by mail-qk1-x744.google.com with SMTP id q22so1190287qkq.6; Tue, 24 Nov 2020 15:46:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=H+rGPaoJ9R3rr7zK4cuxMwlBlLpdlGUAwlQnvIZjZd8=; b=rGjC6KnGzC9NIfLo6IfoTM7C5TiZmv4q08vYNRt8cewMWpFhbX886WW47/gIiopas/ e2jKhT73QJs/dRAIbILcJdQSFnVW9dal1rOBoIKd0ECBe+nqcukIgJrBRfX2wbZlPbrR 27L+0GE9CXpbAta7TZEIdoDweQHp+sEvmypYMH9hyutdrnRkkklGbspFfFiZY+HYfDHj jsH/8tjPy+0JiTdJWitSDoQxXZntWXoEWL0cWLR+fmdpM332GBoSCjfuWUHY88IWDiPh 04ztpEPYlCjpB7IXy1yQhW/otwe7DgKcwtOpyIrk5XdAw3ZKiOAkll08YWpT8S+NhzMx e/Gw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=H+rGPaoJ9R3rr7zK4cuxMwlBlLpdlGUAwlQnvIZjZd8=; b=TuAvjxwjT445lMd0pA19KFC41p7wFL3HpX87iRUSwYKecaY5CUfZGct0eplp4BJ0qb XiLVR9bkLwYNAqYbnPCeCrmFMmzIYCex6DLHYCnXX+zltCNsaCLpjrQx4r/2rmFuFTxp OTWYMwGItGlUPxY9pOrHKkBQk5OsO81nPbRFSRldqVfEmFEQ19oxufnBVpuizZXjTJ3J SqcHKA6zqtjv+8GF30372iB+q1pf4m1+gNSwzQ4iPc9XGNvnJVl3zD9hoBWrYyzUvJg7 rSKHNYAEM+yVkGmxnTuKXOEZmV3wJKia/q5GQqCoZRYdoET7bWZN/1p/1d5q50/73x8u UDrQ== X-Gm-Message-State: AOAM533cWSfF1GKXDPTkXDzUnQ9dFzxyHvitaynzzfrEbImfdlf5kdde /o4zLjdIUAxY8/gXzQXC0P68KCW3n/OI9g4r+DM= X-Google-Smtp-Source: ABdhPJzOwu2wFsHHn8A1YNPfZeoFLdmnMgNDFogUYxSXdSyfkKR4RJ+IXZpEdbdh4p7RHhstmUROclNZOq0Hltp8jFg= X-Received: by 2002:a5b:40e:: with SMTP id m14mr627984ybp.33.1606261594309; Tue, 24 Nov 2020 15:46:34 -0800 (PST) MIME-Version: 1.0 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> In-Reply-To: From: Miguel Ojeda Date: Wed, 25 Nov 2020 00:46:23 +0100 Message-ID: Subject: Re: [PATCH 000/141] Fix fall-through warnings for Clang To: Finn Thain X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201124_184636_515464_638921CF X-CRM114-Status: GOOD ( 20.26 ) 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 Tue, Nov 24, 2020 at 1:58 AM Finn Thain wrote: > > What I meant was that you've used pessimism as if it was fact. "future mistakes that it might prevent" is neither pessimism nor states a fact. > For example, "There is no way to guess what the effect would be if the > compiler trained programmers to add a knee-jerk 'break' statement to avoid > a warning". It is only knee-jerk if you think you are infallible. > Moreover, what I meant was that preventing programmer mistakes is a > problem to be solved by development tools This warning comes from a development tool -- the compiler. > The idea that retro-fitting new > language constructs onto mature code is somehow necessary to "prevent > future mistakes" is entirely questionable. The kernel is not a frozen codebase. Further, "mature code vs. risk of change" arguments don't apply here because the semantics of the program and binary output isn't changing. > Sure. And if you put -Wimplicit-fallthrough into the Makefile and if that > leads to well-intentioned patches that cause regressions, it is partly on > you. Again: adding a `fallthrough` does not change the program semantics. If you are a maintainer and want to cross-check, compare the codegen. > Have you ever considered the overall cost of the countless > -Wpresume-incompetence flags? Yeah: negative. On the other hand, the overall cost of the countless -fI-am-infallible flags is very noticeable. > Perhaps you pay the power bill for a build farm that produces logs that > no-one reads? Perhaps you've run git bisect, knowing that the compiler > messages are not interesting? Or compiled software in using a language > that generates impenetrable messages? If so, here's a tip: > > # grep CFLAGS /etc/portage/make.conf > CFLAGS="... -Wno-all -Wno-extra ..." > CXXFLAGS="${CFLAGS}" > > Now allow me some pessimism: the hardware upgrades, gigawatt hours and > wait time attributable to obligatory static analyses are a net loss. If you really believe compiler warnings and static analysis are useless and costly, I think there is not much point in continuing the discussion. > No, it's not for me to prove that such patches don't affect code > generation. That's for the patch author and (unfortunately) for reviewers. I was not asking you to prove it. I am stating that proving it is very easy. Cheers, Miguel _______________________________________________ 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=-0.5 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, 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 15D26C56201 for ; Tue, 24 Nov 2020 23:46:42 +0000 (UTC) Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136]) (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 6DB3720BED for ; Tue, 24 Nov 2020 23:46:41 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="rGjC6KnG" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6DB3720BED Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=virtualization-bounces@lists.linux-foundation.org Received: from localhost (localhost [127.0.0.1]) by silver.osuosl.org (Postfix) with ESMTP id 1187D232FA; Tue, 24 Nov 2020 23:46:41 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from silver.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n6qz5nNjbnDE; Tue, 24 Nov 2020 23:46:40 +0000 (UTC) Received: from lists.linuxfoundation.org (lf-lists.osuosl.org [140.211.9.56]) by silver.osuosl.org (Postfix) with ESMTP id F3FBE22844; Tue, 24 Nov 2020 23:46:39 +0000 (UTC) Received: from lf-lists.osuosl.org (localhost [127.0.0.1]) by lists.linuxfoundation.org (Postfix) with ESMTP id DE246C1833; Tue, 24 Nov 2020 23:46:39 +0000 (UTC) Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 56D98C0052; Tue, 24 Nov 2020 23:46:38 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by hemlock.osuosl.org (Postfix) with ESMTP id 434A3872EC; Tue, 24 Nov 2020 23:46:38 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from hemlock.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VNHhlEV8wVD7; Tue, 24 Nov 2020 23:46:35 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-qk1-f193.google.com (mail-qk1-f193.google.com [209.85.222.193]) by hemlock.osuosl.org (Postfix) with ESMTPS id 590F486F7C; Tue, 24 Nov 2020 23:46:35 +0000 (UTC) Received: by mail-qk1-f193.google.com with SMTP id d9so1167106qke.8; Tue, 24 Nov 2020 15:46:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=H+rGPaoJ9R3rr7zK4cuxMwlBlLpdlGUAwlQnvIZjZd8=; b=rGjC6KnGzC9NIfLo6IfoTM7C5TiZmv4q08vYNRt8cewMWpFhbX886WW47/gIiopas/ e2jKhT73QJs/dRAIbILcJdQSFnVW9dal1rOBoIKd0ECBe+nqcukIgJrBRfX2wbZlPbrR 27L+0GE9CXpbAta7TZEIdoDweQHp+sEvmypYMH9hyutdrnRkkklGbspFfFiZY+HYfDHj jsH/8tjPy+0JiTdJWitSDoQxXZntWXoEWL0cWLR+fmdpM332GBoSCjfuWUHY88IWDiPh 04ztpEPYlCjpB7IXy1yQhW/otwe7DgKcwtOpyIrk5XdAw3ZKiOAkll08YWpT8S+NhzMx e/Gw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=H+rGPaoJ9R3rr7zK4cuxMwlBlLpdlGUAwlQnvIZjZd8=; b=oH+LmnHGsJhXPuCVyy+Ctxx9OF8FoMlJ9IdOM/NK2fU8eSHrXBF/q62xfrZ+W9c3DR Gb6qg20YPDnvSo9b59Q3zDlsy+J2+Lm31i4LptzngTQjrM9rlFrbrUPAzv1UQELm+I7+ sQQ3oFmj1n8QrAoP4YAMfDVJWFac5IjaH0e9aWfd1zAMiDst3lYRB5B0yJqcKU1124VE WHK3c8taXVoSc4OQgZ+B+FxsWP30ozpHUtYIXQgja2c9rq+BDUEWpSxRqP0XelhUCA93 9LRL4z784b8viJCD04kLX6tYnVSvwRDPJauHGLcuBGF2ZeRqFCNGW7cytKsiDvYrkt/S 97BA== X-Gm-Message-State: AOAM5316Ib6tLe6c5E0WLZeEK82kjvIhN6EGxSVT0opxpGAgE+jFTJu0 9fj52fisY3DxOrc94TGJQzPivBZn6vPsust0Tzw= X-Google-Smtp-Source: ABdhPJzOwu2wFsHHn8A1YNPfZeoFLdmnMgNDFogUYxSXdSyfkKR4RJ+IXZpEdbdh4p7RHhstmUROclNZOq0Hltp8jFg= X-Received: by 2002:a5b:40e:: with SMTP id m14mr627984ybp.33.1606261594309; Tue, 24 Nov 2020 15:46:34 -0800 (PST) MIME-Version: 1.0 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> In-Reply-To: From: Miguel Ojeda Date: Wed, 25 Nov 2020 00:46:23 +0100 Message-ID: Subject: Re: [PATCH 000/141] Fix fall-through warnings for Clang To: Finn Thain 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: virtualization@lists.linux-foundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Linux virtualization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: virtualization-bounces@lists.linux-foundation.org Sender: "Virtualization" On Tue, Nov 24, 2020 at 1:58 AM Finn Thain wrote: > > What I meant was that you've used pessimism as if it was fact. "future mistakes that it might prevent" is neither pessimism nor states a fact. > For example, "There is no way to guess what the effect would be if the > compiler trained programmers to add a knee-jerk 'break' statement to avoid > a warning". It is only knee-jerk if you think you are infallible. > Moreover, what I meant was that preventing programmer mistakes is a > problem to be solved by development tools This warning comes from a development tool -- the compiler. > The idea that retro-fitting new > language constructs onto mature code is somehow necessary to "prevent > future mistakes" is entirely questionable. The kernel is not a frozen codebase. Further, "mature code vs. risk of change" arguments don't apply here because the semantics of the program and binary output isn't changing. > Sure. And if you put -Wimplicit-fallthrough into the Makefile and if that > leads to well-intentioned patches that cause regressions, it is partly on > you. Again: adding a `fallthrough` does not change the program semantics. If you are a maintainer and want to cross-check, compare the codegen. > Have you ever considered the overall cost of the countless > -Wpresume-incompetence flags? Yeah: negative. On the other hand, the overall cost of the countless -fI-am-infallible flags is very noticeable. > Perhaps you pay the power bill for a build farm that produces logs that > no-one reads? Perhaps you've run git bisect, knowing that the compiler > messages are not interesting? Or compiled software in using a language > that generates impenetrable messages? If so, here's a tip: > > # grep CFLAGS /etc/portage/make.conf > CFLAGS="... -Wno-all -Wno-extra ..." > CXXFLAGS="${CFLAGS}" > > Now allow me some pessimism: the hardware upgrades, gigawatt hours and > wait time attributable to obligatory static analyses are a net loss. If you really believe compiler warnings and static analysis are useless and costly, I think there is not much point in continuing the discussion. > No, it's not for me to prove that such patches don't affect code > generation. That's for the patch author and (unfortunately) for reviewers. I was not asking you to prove it. I am stating that proving it is very easy. Cheers, Miguel _______________________________________________ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization 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=-0.5 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, 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 98E15C56201 for ; Wed, 25 Nov 2020 08:13:17 +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 2B73B20B80 for ; Wed, 25 Nov 2020 08:13:17 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="rGjC6KnG" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2B73B20B80 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com 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 702556E868; Wed, 25 Nov 2020 08:13:00 +0000 (UTC) Received: from mail-qk1-x743.google.com (mail-qk1-x743.google.com [IPv6:2607:f8b0:4864:20::743]) by gabe.freedesktop.org (Postfix) with ESMTPS id 1E9F96E5CA; Tue, 24 Nov 2020 23:46:35 +0000 (UTC) Received: by mail-qk1-x743.google.com with SMTP id q5so1122895qkc.12; Tue, 24 Nov 2020 15:46:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=H+rGPaoJ9R3rr7zK4cuxMwlBlLpdlGUAwlQnvIZjZd8=; b=rGjC6KnGzC9NIfLo6IfoTM7C5TiZmv4q08vYNRt8cewMWpFhbX886WW47/gIiopas/ e2jKhT73QJs/dRAIbILcJdQSFnVW9dal1rOBoIKd0ECBe+nqcukIgJrBRfX2wbZlPbrR 27L+0GE9CXpbAta7TZEIdoDweQHp+sEvmypYMH9hyutdrnRkkklGbspFfFiZY+HYfDHj jsH/8tjPy+0JiTdJWitSDoQxXZntWXoEWL0cWLR+fmdpM332GBoSCjfuWUHY88IWDiPh 04ztpEPYlCjpB7IXy1yQhW/otwe7DgKcwtOpyIrk5XdAw3ZKiOAkll08YWpT8S+NhzMx e/Gw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=H+rGPaoJ9R3rr7zK4cuxMwlBlLpdlGUAwlQnvIZjZd8=; b=TYffeSRbe43ODMjM/MAQ0pbAsS+9hDYoSLz32LAh9hG9Op3JqBa3V4pOJtni0SuVPt 1MOmhxEWNAl2DdpdTS1iSpV1xdxvr3lquvTXNSAWs8BGTg8jVHrqxdZ6mUecAQML3n+h D5moQqhzVSJKYgIEWxcvwzgzRA6oM4fjUey/Qk5neci8zl/wIUC82m/lTVf/53Su4I8x JVyXLaVJnMXye/bMOO4330yCxyj75ovqSQKGpel6mDvKd/71heGA84hO3I2tcypRLsgw GMYFMpIQwyS9rFMowtraYpvGAljs9KX23R+2aXs71p+popqfItFuIHM7b3G5ltxNAZyQ LTbw== X-Gm-Message-State: AOAM53365CnpBUGHPLw4uGuAoAc1XyZOiK4R7TTOkmnCb2CpG4z9Ll6U qG0ptjliax1TesISt3SpA5sjgZvXgBp/gut6NLc= X-Google-Smtp-Source: ABdhPJzOwu2wFsHHn8A1YNPfZeoFLdmnMgNDFogUYxSXdSyfkKR4RJ+IXZpEdbdh4p7RHhstmUROclNZOq0Hltp8jFg= X-Received: by 2002:a5b:40e:: with SMTP id m14mr627984ybp.33.1606261594309; Tue, 24 Nov 2020 15:46:34 -0800 (PST) MIME-Version: 1.0 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> In-Reply-To: From: Miguel Ojeda Date: Wed, 25 Nov 2020 00:46:23 +0100 Message-ID: Subject: Re: [PATCH 000/141] Fix fall-through warnings for Clang To: Finn Thain X-Mailman-Approved-At: Wed, 25 Nov 2020 08:11:52 +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 Tue, Nov 24, 2020 at 1:58 AM Finn Thain wrote: > > What I meant was that you've used pessimism as if it was fact. "future mistakes that it might prevent" is neither pessimism nor states a fact. > For example, "There is no way to guess what the effect would be if the > compiler trained programmers to add a knee-jerk 'break' statement to avoid > a warning". It is only knee-jerk if you think you are infallible. > Moreover, what I meant was that preventing programmer mistakes is a > problem to be solved by development tools This warning comes from a development tool -- the compiler. > The idea that retro-fitting new > language constructs onto mature code is somehow necessary to "prevent > future mistakes" is entirely questionable. The kernel is not a frozen codebase. Further, "mature code vs. risk of change" arguments don't apply here because the semantics of the program and binary output isn't changing. > Sure. And if you put -Wimplicit-fallthrough into the Makefile and if that > leads to well-intentioned patches that cause regressions, it is partly on > you. Again: adding a `fallthrough` does not change the program semantics. If you are a maintainer and want to cross-check, compare the codegen. > Have you ever considered the overall cost of the countless > -Wpresume-incompetence flags? Yeah: negative. On the other hand, the overall cost of the countless -fI-am-infallible flags is very noticeable. > Perhaps you pay the power bill for a build farm that produces logs that > no-one reads? Perhaps you've run git bisect, knowing that the compiler > messages are not interesting? Or compiled software in using a language > that generates impenetrable messages? If so, here's a tip: > > # grep CFLAGS /etc/portage/make.conf > CFLAGS="... -Wno-all -Wno-extra ..." > CXXFLAGS="${CFLAGS}" > > Now allow me some pessimism: the hardware upgrades, gigawatt hours and > wait time attributable to obligatory static analyses are a net loss. If you really believe compiler warnings and static analysis are useless and costly, I think there is not much point in continuing the discussion. > No, it's not for me to prove that such patches don't affect code > generation. That's for the patch author and (unfortunately) for reviewers. I was not asking you to prove it. I am stating that proving it is very easy. Cheers, Miguel _______________________________________________ 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=-0.7 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,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 0CAB2C5519F for ; Wed, 25 Nov 2020 07:16:24 +0000 (UTC) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.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 5D2E420B1F for ; Wed, 25 Nov 2020 07:16:23 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5D2E420B1F Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com 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-61-V8vYgIFkN02GOg5GkbYyiQ-1; Wed, 25 Nov 2020 02:16:19 -0500 X-MC-Unique: V8vYgIFkN02GOg5GkbYyiQ-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id CBEE0190A7A4; Wed, 25 Nov 2020 07:16:14 +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 AF8A55D9C2; Wed, 25 Nov 2020 07:16:14 +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 857CC3773; Wed, 25 Nov 2020 07:16:14 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id 0AONke3S005943 for ; Tue, 24 Nov 2020 18:46:40 -0500 Received: by smtp.corp.redhat.com (Postfix) id 070AF2026D25; Tue, 24 Nov 2020 23:46:40 +0000 (UTC) Received: from mimecast-mx02.redhat.com (mimecast02.extmail.prod.ext.rdu2.redhat.com [10.11.55.18]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 0203D2026D46 for ; Tue, 24 Nov 2020 23:46:37 +0000 (UTC) Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.120]) (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 A595C8007DF for ; Tue, 24 Nov 2020 23:46:37 +0000 (UTC) Received: from mail-qk1-f194.google.com (mail-qk1-f194.google.com [209.85.222.194]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-312-cU6iHb9fN7Sf8iXqUK4aSA-1; Tue, 24 Nov 2020 18:46:34 -0500 X-MC-Unique: cU6iHb9fN7Sf8iXqUK4aSA-1 Received: by mail-qk1-f194.google.com with SMTP id y197so1176465qkb.7; Tue, 24 Nov 2020 15:46:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=H+rGPaoJ9R3rr7zK4cuxMwlBlLpdlGUAwlQnvIZjZd8=; b=IckOAH55h+Mv4pEbIEiNCbqegcGE2GiTiLiWxEm1ao3pHQD3+ZJ0T62HcnOyXOTWXM KNctlf7/7Bev2KIUxv4+wAKUztnbbAEsm+Zi4rNgqUAyJuGQSHrgsFVJ1tt5CTiwmoEU T6b4LkPW8j/WABCXWqcERRpseTwUPQosVYr+6diDYF6yqxb+EmS9UlwuTVNG2oS/3BBy I+ZW5BYhPXOfj4uAMteRgiRvnPIsqdpdMA1rfZmaK+CWqi7fn3SBuz37NnLyZWdUT2X7 k4gmOfRNUQnaKgKksv+N61E4xHJCznu9RSaSGqbOulXuW8gpGBkHmnmlEAPqZ0diAtc0 vdfw== X-Gm-Message-State: AOAM533teMXcavYigEKNiDgeajvbNqa3Zh6p52ER4bAVqdElpcI1Tkf6 HwMVtKf0Vsw1I2Jd2kltL4/4vjrb1a2wdL9YPVE= X-Google-Smtp-Source: ABdhPJzOwu2wFsHHn8A1YNPfZeoFLdmnMgNDFogUYxSXdSyfkKR4RJ+IXZpEdbdh4p7RHhstmUROclNZOq0Hltp8jFg= X-Received: by 2002:a5b:40e:: with SMTP id m14mr627984ybp.33.1606261594309; Tue, 24 Nov 2020 15:46:34 -0800 (PST) MIME-Version: 1.0 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> In-Reply-To: From: Miguel Ojeda Date: Wed, 25 Nov 2020 00:46:23 +0100 Message-ID: To: Finn Thain 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.4 X-loop: dm-devel@redhat.com X-Mailman-Approved-At: Wed, 25 Nov 2020 02:15:21 -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.14 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 Tue, Nov 24, 2020 at 1:58 AM Finn Thain wrote: > > What I meant was that you've used pessimism as if it was fact. "future mistakes that it might prevent" is neither pessimism nor states a fact. > For example, "There is no way to guess what the effect would be if the > compiler trained programmers to add a knee-jerk 'break' statement to avoid > a warning". It is only knee-jerk if you think you are infallible. > Moreover, what I meant was that preventing programmer mistakes is a > problem to be solved by development tools This warning comes from a development tool -- the compiler. > The idea that retro-fitting new > language constructs onto mature code is somehow necessary to "prevent > future mistakes" is entirely questionable. The kernel is not a frozen codebase. Further, "mature code vs. risk of change" arguments don't apply here because the semantics of the program and binary output isn't changing. > Sure. And if you put -Wimplicit-fallthrough into the Makefile and if that > leads to well-intentioned patches that cause regressions, it is partly on > you. Again: adding a `fallthrough` does not change the program semantics. If you are a maintainer and want to cross-check, compare the codegen. > Have you ever considered the overall cost of the countless > -Wpresume-incompetence flags? Yeah: negative. On the other hand, the overall cost of the countless -fI-am-infallible flags is very noticeable. > Perhaps you pay the power bill for a build farm that produces logs that > no-one reads? Perhaps you've run git bisect, knowing that the compiler > messages are not interesting? Or compiled software in using a language > that generates impenetrable messages? If so, here's a tip: > > # grep CFLAGS /etc/portage/make.conf > CFLAGS="... -Wno-all -Wno-extra ..." > CXXFLAGS="${CFLAGS}" > > Now allow me some pessimism: the hardware upgrades, gigawatt hours and > wait time attributable to obligatory static analyses are a net loss. If you really believe compiler warnings and static analysis are useless and costly, I think there is not much point in continuing the discussion. > No, it's not for me to prove that such patches don't affect code > generation. That's for the patch author and (unfortunately) for reviewers. I was not asking you to prove it. I am stating that proving it is very easy. Cheers, Miguel -- 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=-0.5 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, 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 67A79C5519F for ; Wed, 25 Nov 2020 06:26:30 +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 E44082075A for ; Wed, 25 Nov 2020 06:26:29 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="rGjC6KnG" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E44082075A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com 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 F0BA86E81C; Wed, 25 Nov 2020 06:26:28 +0000 (UTC) Received: from mail-qk1-x743.google.com (mail-qk1-x743.google.com [IPv6:2607:f8b0:4864:20::743]) by gabe.freedesktop.org (Postfix) with ESMTPS id 1E9F96E5CA; Tue, 24 Nov 2020 23:46:35 +0000 (UTC) Received: by mail-qk1-x743.google.com with SMTP id q5so1122895qkc.12; Tue, 24 Nov 2020 15:46:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=H+rGPaoJ9R3rr7zK4cuxMwlBlLpdlGUAwlQnvIZjZd8=; b=rGjC6KnGzC9NIfLo6IfoTM7C5TiZmv4q08vYNRt8cewMWpFhbX886WW47/gIiopas/ e2jKhT73QJs/dRAIbILcJdQSFnVW9dal1rOBoIKd0ECBe+nqcukIgJrBRfX2wbZlPbrR 27L+0GE9CXpbAta7TZEIdoDweQHp+sEvmypYMH9hyutdrnRkkklGbspFfFiZY+HYfDHj jsH/8tjPy+0JiTdJWitSDoQxXZntWXoEWL0cWLR+fmdpM332GBoSCjfuWUHY88IWDiPh 04ztpEPYlCjpB7IXy1yQhW/otwe7DgKcwtOpyIrk5XdAw3ZKiOAkll08YWpT8S+NhzMx e/Gw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=H+rGPaoJ9R3rr7zK4cuxMwlBlLpdlGUAwlQnvIZjZd8=; b=TYffeSRbe43ODMjM/MAQ0pbAsS+9hDYoSLz32LAh9hG9Op3JqBa3V4pOJtni0SuVPt 1MOmhxEWNAl2DdpdTS1iSpV1xdxvr3lquvTXNSAWs8BGTg8jVHrqxdZ6mUecAQML3n+h D5moQqhzVSJKYgIEWxcvwzgzRA6oM4fjUey/Qk5neci8zl/wIUC82m/lTVf/53Su4I8x JVyXLaVJnMXye/bMOO4330yCxyj75ovqSQKGpel6mDvKd/71heGA84hO3I2tcypRLsgw GMYFMpIQwyS9rFMowtraYpvGAljs9KX23R+2aXs71p+popqfItFuIHM7b3G5ltxNAZyQ LTbw== X-Gm-Message-State: AOAM53365CnpBUGHPLw4uGuAoAc1XyZOiK4R7TTOkmnCb2CpG4z9Ll6U qG0ptjliax1TesISt3SpA5sjgZvXgBp/gut6NLc= X-Google-Smtp-Source: ABdhPJzOwu2wFsHHn8A1YNPfZeoFLdmnMgNDFogUYxSXdSyfkKR4RJ+IXZpEdbdh4p7RHhstmUROclNZOq0Hltp8jFg= X-Received: by 2002:a5b:40e:: with SMTP id m14mr627984ybp.33.1606261594309; Tue, 24 Nov 2020 15:46:34 -0800 (PST) MIME-Version: 1.0 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> In-Reply-To: From: Miguel Ojeda Date: Wed, 25 Nov 2020 00:46:23 +0100 Message-ID: To: Finn Thain X-Mailman-Approved-At: Wed, 25 Nov 2020 06:26:28 +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 Tue, Nov 24, 2020 at 1:58 AM Finn Thain wrote: > > What I meant was that you've used pessimism as if it was fact. "future mistakes that it might prevent" is neither pessimism nor states a fact. > For example, "There is no way to guess what the effect would be if the > compiler trained programmers to add a knee-jerk 'break' statement to avoid > a warning". It is only knee-jerk if you think you are infallible. > Moreover, what I meant was that preventing programmer mistakes is a > problem to be solved by development tools This warning comes from a development tool -- the compiler. > The idea that retro-fitting new > language constructs onto mature code is somehow necessary to "prevent > future mistakes" is entirely questionable. The kernel is not a frozen codebase. Further, "mature code vs. risk of change" arguments don't apply here because the semantics of the program and binary output isn't changing. > Sure. And if you put -Wimplicit-fallthrough into the Makefile and if that > leads to well-intentioned patches that cause regressions, it is partly on > you. Again: adding a `fallthrough` does not change the program semantics. If you are a maintainer and want to cross-check, compare the codegen. > Have you ever considered the overall cost of the countless > -Wpresume-incompetence flags? Yeah: negative. On the other hand, the overall cost of the countless -fI-am-infallible flags is very noticeable. > Perhaps you pay the power bill for a build farm that produces logs that > no-one reads? Perhaps you've run git bisect, knowing that the compiler > messages are not interesting? Or compiled software in using a language > that generates impenetrable messages? If so, here's a tip: > > # grep CFLAGS /etc/portage/make.conf > CFLAGS="... -Wno-all -Wno-extra ..." > CXXFLAGS="${CFLAGS}" > > Now allow me some pessimism: the hardware upgrades, gigawatt hours and > wait time attributable to obligatory static analyses are a net loss. If you really believe compiler warnings and static analysis are useless and costly, I think there is not much point in continuing the discussion. > No, it's not for me to prove that such patches don't affect code > generation. That's for the patch author and (unfortunately) for reviewers. I was not asking you to prove it. I am stating that proving it is very easy. Cheers, Miguel _______________________________________________ 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=-0.5 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, 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 A27EDC83010 for ; Wed, 25 Nov 2020 08:23:24 +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 355B5208C3 for ; Wed, 25 Nov 2020 08:23:24 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="rGjC6KnG" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 355B5208C3 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com 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 11B6E6E96B; Wed, 25 Nov 2020 08:23:02 +0000 (UTC) Received: from mail-qk1-x743.google.com (mail-qk1-x743.google.com [IPv6:2607:f8b0:4864:20::743]) by gabe.freedesktop.org (Postfix) with ESMTPS id 1E9F96E5CA; Tue, 24 Nov 2020 23:46:35 +0000 (UTC) Received: by mail-qk1-x743.google.com with SMTP id q5so1122895qkc.12; Tue, 24 Nov 2020 15:46:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=H+rGPaoJ9R3rr7zK4cuxMwlBlLpdlGUAwlQnvIZjZd8=; b=rGjC6KnGzC9NIfLo6IfoTM7C5TiZmv4q08vYNRt8cewMWpFhbX886WW47/gIiopas/ e2jKhT73QJs/dRAIbILcJdQSFnVW9dal1rOBoIKd0ECBe+nqcukIgJrBRfX2wbZlPbrR 27L+0GE9CXpbAta7TZEIdoDweQHp+sEvmypYMH9hyutdrnRkkklGbspFfFiZY+HYfDHj jsH/8tjPy+0JiTdJWitSDoQxXZntWXoEWL0cWLR+fmdpM332GBoSCjfuWUHY88IWDiPh 04ztpEPYlCjpB7IXy1yQhW/otwe7DgKcwtOpyIrk5XdAw3ZKiOAkll08YWpT8S+NhzMx e/Gw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=H+rGPaoJ9R3rr7zK4cuxMwlBlLpdlGUAwlQnvIZjZd8=; b=TYffeSRbe43ODMjM/MAQ0pbAsS+9hDYoSLz32LAh9hG9Op3JqBa3V4pOJtni0SuVPt 1MOmhxEWNAl2DdpdTS1iSpV1xdxvr3lquvTXNSAWs8BGTg8jVHrqxdZ6mUecAQML3n+h D5moQqhzVSJKYgIEWxcvwzgzRA6oM4fjUey/Qk5neci8zl/wIUC82m/lTVf/53Su4I8x JVyXLaVJnMXye/bMOO4330yCxyj75ovqSQKGpel6mDvKd/71heGA84hO3I2tcypRLsgw GMYFMpIQwyS9rFMowtraYpvGAljs9KX23R+2aXs71p+popqfItFuIHM7b3G5ltxNAZyQ LTbw== X-Gm-Message-State: AOAM53365CnpBUGHPLw4uGuAoAc1XyZOiK4R7TTOkmnCb2CpG4z9Ll6U qG0ptjliax1TesISt3SpA5sjgZvXgBp/gut6NLc= X-Google-Smtp-Source: ABdhPJzOwu2wFsHHn8A1YNPfZeoFLdmnMgNDFogUYxSXdSyfkKR4RJ+IXZpEdbdh4p7RHhstmUROclNZOq0Hltp8jFg= X-Received: by 2002:a5b:40e:: with SMTP id m14mr627984ybp.33.1606261594309; Tue, 24 Nov 2020 15:46:34 -0800 (PST) MIME-Version: 1.0 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> In-Reply-To: From: Miguel Ojeda Date: Wed, 25 Nov 2020 00:46:23 +0100 Message-ID: Subject: Re: [PATCH 000/141] Fix fall-through warnings for Clang To: Finn Thain X-Mailman-Approved-At: Wed, 25 Nov 2020 08:22:58 +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 Tue, Nov 24, 2020 at 1:58 AM Finn Thain wrote: > > What I meant was that you've used pessimism as if it was fact. "future mistakes that it might prevent" is neither pessimism nor states a fact. > For example, "There is no way to guess what the effect would be if the > compiler trained programmers to add a knee-jerk 'break' statement to avoid > a warning". It is only knee-jerk if you think you are infallible. > Moreover, what I meant was that preventing programmer mistakes is a > problem to be solved by development tools This warning comes from a development tool -- the compiler. > The idea that retro-fitting new > language constructs onto mature code is somehow necessary to "prevent > future mistakes" is entirely questionable. The kernel is not a frozen codebase. Further, "mature code vs. risk of change" arguments don't apply here because the semantics of the program and binary output isn't changing. > Sure. And if you put -Wimplicit-fallthrough into the Makefile and if that > leads to well-intentioned patches that cause regressions, it is partly on > you. Again: adding a `fallthrough` does not change the program semantics. If you are a maintainer and want to cross-check, compare the codegen. > Have you ever considered the overall cost of the countless > -Wpresume-incompetence flags? Yeah: negative. On the other hand, the overall cost of the countless -fI-am-infallible flags is very noticeable. > Perhaps you pay the power bill for a build farm that produces logs that > no-one reads? Perhaps you've run git bisect, knowing that the compiler > messages are not interesting? Or compiled software in using a language > that generates impenetrable messages? If so, here's a tip: > > # grep CFLAGS /etc/portage/make.conf > CFLAGS="... -Wno-all -Wno-extra ..." > CXXFLAGS="${CFLAGS}" > > Now allow me some pessimism: the hardware upgrades, gigawatt hours and > wait time attributable to obligatory static analyses are a net loss. If you really believe compiler warnings and static analysis are useless and costly, I think there is not much point in continuing the discussion. > No, it's not for me to prove that such patches don't affect code > generation. That's for the patch author and (unfortunately) for reviewers. I was not asking you to prove it. I am stating that proving it is very easy. Cheers, Miguel _______________________________________________ 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=-0.7 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,DKIM_VALID,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, 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 0C6B9C64E75 for ; Wed, 25 Nov 2020 09:57:30 +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 8F9592083E for ; Wed, 25 Nov 2020 09:57:29 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="Se58Gqf3"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="rGjC6KnG" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8F9592083E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com 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:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=7KgUfnvT7adb/XnUVbPkE9EvBXIB/FTs3wpXoJBmmCQ=; b=Se58Gqf3xxp+ANPQJoAdvtUD6 sHQMdJdfpsKrfV+6+W0TolVa6JKhXieZwlUaa9azkXRHLNbJiaD+U4TyE+ZwnUf7rzI+GgJK8x9Ii imEGFr6cdQF7/BfXN0lMtnfHwEtngFf8kPoQrT/p8rUs4knAE8pBNLdKRfZH/ChuCfccm+9uQAB/N A0ieOLjiibQ4SoPIBCzS5TXEtJOY900KiFOr67d2rbU1yUmbh098mT1EZIgbcl4uRErvAviar3S7w ybdqinujFKoQ5AEa6HQtymKIFe+vH0VHa1cUDKXE0qSHP+Q0njIVL0F/oNacc7j1LQoiK2nph4zft rFfPBmojA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1khrYG-0006bM-RQ; Wed, 25 Nov 2020 09:57:28 +0000 Received: from mail-qk1-x744.google.com ([2607:f8b0:4864:20::744]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1khi16-0007Fo-9K; Tue, 24 Nov 2020 23:46:37 +0000 Received: by mail-qk1-x744.google.com with SMTP id q22so1190287qkq.6; Tue, 24 Nov 2020 15:46:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=H+rGPaoJ9R3rr7zK4cuxMwlBlLpdlGUAwlQnvIZjZd8=; b=rGjC6KnGzC9NIfLo6IfoTM7C5TiZmv4q08vYNRt8cewMWpFhbX886WW47/gIiopas/ e2jKhT73QJs/dRAIbILcJdQSFnVW9dal1rOBoIKd0ECBe+nqcukIgJrBRfX2wbZlPbrR 27L+0GE9CXpbAta7TZEIdoDweQHp+sEvmypYMH9hyutdrnRkkklGbspFfFiZY+HYfDHj jsH/8tjPy+0JiTdJWitSDoQxXZntWXoEWL0cWLR+fmdpM332GBoSCjfuWUHY88IWDiPh 04ztpEPYlCjpB7IXy1yQhW/otwe7DgKcwtOpyIrk5XdAw3ZKiOAkll08YWpT8S+NhzMx e/Gw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=H+rGPaoJ9R3rr7zK4cuxMwlBlLpdlGUAwlQnvIZjZd8=; b=TuAvjxwjT445lMd0pA19KFC41p7wFL3HpX87iRUSwYKecaY5CUfZGct0eplp4BJ0qb XiLVR9bkLwYNAqYbnPCeCrmFMmzIYCex6DLHYCnXX+zltCNsaCLpjrQx4r/2rmFuFTxp OTWYMwGItGlUPxY9pOrHKkBQk5OsO81nPbRFSRldqVfEmFEQ19oxufnBVpuizZXjTJ3J SqcHKA6zqtjv+8GF30372iB+q1pf4m1+gNSwzQ4iPc9XGNvnJVl3zD9hoBWrYyzUvJg7 rSKHNYAEM+yVkGmxnTuKXOEZmV3wJKia/q5GQqCoZRYdoET7bWZN/1p/1d5q50/73x8u UDrQ== X-Gm-Message-State: AOAM533cWSfF1GKXDPTkXDzUnQ9dFzxyHvitaynzzfrEbImfdlf5kdde /o4zLjdIUAxY8/gXzQXC0P68KCW3n/OI9g4r+DM= X-Google-Smtp-Source: ABdhPJzOwu2wFsHHn8A1YNPfZeoFLdmnMgNDFogUYxSXdSyfkKR4RJ+IXZpEdbdh4p7RHhstmUROclNZOq0Hltp8jFg= X-Received: by 2002:a5b:40e:: with SMTP id m14mr627984ybp.33.1606261594309; Tue, 24 Nov 2020 15:46:34 -0800 (PST) MIME-Version: 1.0 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> In-Reply-To: From: Miguel Ojeda Date: Wed, 25 Nov 2020 00:46:23 +0100 Message-ID: Subject: Re: [PATCH 000/141] Fix fall-through warnings for Clang To: Finn Thain X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201124_184636_515464_638921CF X-CRM114-Status: GOOD ( 20.26 ) 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 Tue, Nov 24, 2020 at 1:58 AM Finn Thain wrote: > > What I meant was that you've used pessimism as if it was fact. "future mistakes that it might prevent" is neither pessimism nor states a fact. > For example, "There is no way to guess what the effect would be if the > compiler trained programmers to add a knee-jerk 'break' statement to avoid > a warning". It is only knee-jerk if you think you are infallible. > Moreover, what I meant was that preventing programmer mistakes is a > problem to be solved by development tools This warning comes from a development tool -- the compiler. > The idea that retro-fitting new > language constructs onto mature code is somehow necessary to "prevent > future mistakes" is entirely questionable. The kernel is not a frozen codebase. Further, "mature code vs. risk of change" arguments don't apply here because the semantics of the program and binary output isn't changing. > Sure. And if you put -Wimplicit-fallthrough into the Makefile and if that > leads to well-intentioned patches that cause regressions, it is partly on > you. Again: adding a `fallthrough` does not change the program semantics. If you are a maintainer and want to cross-check, compare the codegen. > Have you ever considered the overall cost of the countless > -Wpresume-incompetence flags? Yeah: negative. On the other hand, the overall cost of the countless -fI-am-infallible flags is very noticeable. > Perhaps you pay the power bill for a build farm that produces logs that > no-one reads? Perhaps you've run git bisect, knowing that the compiler > messages are not interesting? Or compiled software in using a language > that generates impenetrable messages? If so, here's a tip: > > # grep CFLAGS /etc/portage/make.conf > CFLAGS="... -Wno-all -Wno-extra ..." > CXXFLAGS="${CFLAGS}" > > Now allow me some pessimism: the hardware upgrades, gigawatt hours and > wait time attributable to obligatory static analyses are a net loss. If you really believe compiler warnings and static analysis are useless and costly, I think there is not much point in continuing the discussion. > No, it's not for me to prove that such patches don't affect code > generation. That's for the patch author and (unfortunately) for reviewers. I was not asking you to prove it. I am stating that proving it is very easy. Cheers, Miguel -- 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: Miguel Ojeda Date: Wed, 25 Nov 2020 00:46:23 +0100 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 Tue, Nov 24, 2020 at 1:58 AM Finn Thain wrote: > > What I meant was that you've used pessimism as if it was fact. "future mistakes that it might prevent" is neither pessimism nor states a fact. > For example, "There is no way to guess what the effect would be if the > compiler trained programmers to add a knee-jerk 'break' statement to avoid > a warning". It is only knee-jerk if you think you are infallible. > Moreover, what I meant was that preventing programmer mistakes is a > problem to be solved by development tools This warning comes from a development tool -- the compiler. > The idea that retro-fitting new > language constructs onto mature code is somehow necessary to "prevent > future mistakes" is entirely questionable. The kernel is not a frozen codebase. Further, "mature code vs. risk of change" arguments don't apply here because the semantics of the program and binary output isn't changing. > Sure. And if you put -Wimplicit-fallthrough into the Makefile and if that > leads to well-intentioned patches that cause regressions, it is partly on > you. Again: adding a `fallthrough` does not change the program semantics. If you are a maintainer and want to cross-check, compare the codegen. > Have you ever considered the overall cost of the countless > -Wpresume-incompetence flags? Yeah: negative. On the other hand, the overall cost of the countless -fI-am-infallible flags is very noticeable. > Perhaps you pay the power bill for a build farm that produces logs that > no-one reads? Perhaps you've run git bisect, knowing that the compiler > messages are not interesting? Or compiled software in using a language > that generates impenetrable messages? If so, here's a tip: > > # grep CFLAGS /etc/portage/make.conf > CFLAGS="... -Wno-all -Wno-extra ..." > CXXFLAGS="${CFLAGS}" > > Now allow me some pessimism: the hardware upgrades, gigawatt hours and > wait time attributable to obligatory static analyses are a net loss. If you really believe compiler warnings and static analysis are useless and costly, I think there is not much point in continuing the discussion. > No, it's not for me to prove that such patches don't affect code > generation. That's for the patch author and (unfortunately) for reviewers. I was not asking you to prove it. I am stating that proving it is very easy. Cheers, Miguel From mboxrd@z Thu Jan 1 00:00:00 1970 From: Miguel Ojeda Date: Wed, 25 Nov 2020 00:46:23 +0100 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 Tue, Nov 24, 2020 at 1:58 AM Finn Thain wrote: > > What I meant was that you've used pessimism as if it was fact. "future mistakes that it might prevent" is neither pessimism nor states a fact. > For example, "There is no way to guess what the effect would be if the > compiler trained programmers to add a knee-jerk 'break' statement to avoid > a warning". It is only knee-jerk if you think you are infallible. > Moreover, what I meant was that preventing programmer mistakes is a > problem to be solved by development tools This warning comes from a development tool -- the compiler. > The idea that retro-fitting new > language constructs onto mature code is somehow necessary to "prevent > future mistakes" is entirely questionable. The kernel is not a frozen codebase. Further, "mature code vs. risk of change" arguments don't apply here because the semantics of the program and binary output isn't changing. > Sure. And if you put -Wimplicit-fallthrough into the Makefile and if that > leads to well-intentioned patches that cause regressions, it is partly on > you. Again: adding a `fallthrough` does not change the program semantics. If you are a maintainer and want to cross-check, compare the codegen. > Have you ever considered the overall cost of the countless > -Wpresume-incompetence flags? Yeah: negative. On the other hand, the overall cost of the countless -fI-am-infallible flags is very noticeable. > Perhaps you pay the power bill for a build farm that produces logs that > no-one reads? Perhaps you've run git bisect, knowing that the compiler > messages are not interesting? Or compiled software in using a language > that generates impenetrable messages? If so, here's a tip: > > # grep CFLAGS /etc/portage/make.conf > CFLAGS="... -Wno-all -Wno-extra ..." > CXXFLAGS="${CFLAGS}" > > Now allow me some pessimism: the hardware upgrades, gigawatt hours and > wait time attributable to obligatory static analyses are a net loss. If you really believe compiler warnings and static analysis are useless and costly, I think there is not much point in continuing the discussion. > No, it's not for me to prove that such patches don't affect code > generation. That's for the patch author and (unfortunately) for reviewers. I was not asking you to prove it. I am stating that proving it is very easy. Cheers, Miguel From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=H+rGPaoJ9R3rr7zK4cuxMwlBlLpdlGUAwlQnvIZjZd8=; b=rGjC6KnGzC9NIfLo6IfoTM7C5TiZmv4q08vYNRt8cewMWpFhbX886WW47/gIiopas/ e2jKhT73QJs/dRAIbILcJdQSFnVW9dal1rOBoIKd0ECBe+nqcukIgJrBRfX2wbZlPbrR 27L+0GE9CXpbAta7TZEIdoDweQHp+sEvmypYMH9hyutdrnRkkklGbspFfFiZY+HYfDHj jsH/8tjPy+0JiTdJWitSDoQxXZntWXoEWL0cWLR+fmdpM332GBoSCjfuWUHY88IWDiPh 04ztpEPYlCjpB7IXy1yQhW/otwe7DgKcwtOpyIrk5XdAw3ZKiOAkll08YWpT8S+NhzMx e/Gw== MIME-Version: 1.0 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> In-Reply-To: From: Miguel Ojeda Date: Wed, 25 Nov 2020 00:46:23 +0100 Message-ID: Content-Type: text/plain; charset="UTF-8" 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: Finn Thain 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 Tue, Nov 24, 2020 at 1:58 AM Finn Thain wrote: > > What I meant was that you've used pessimism as if it was fact. "future mistakes that it might prevent" is neither pessimism nor states a fact. > For example, "There is no way to guess what the effect would be if the > compiler trained programmers to add a knee-jerk 'break' statement to avoid > a warning". It is only knee-jerk if you think you are infallible. > Moreover, what I meant was that preventing programmer mistakes is a > problem to be solved by development tools This warning comes from a development tool -- the compiler. > The idea that retro-fitting new > language constructs onto mature code is somehow necessary to "prevent > future mistakes" is entirely questionable. The kernel is not a frozen codebase. Further, "mature code vs. risk of change" arguments don't apply here because the semantics of the program and binary output isn't changing. > Sure. And if you put -Wimplicit-fallthrough into the Makefile and if that > leads to well-intentioned patches that cause regressions, it is partly on > you. Again: adding a `fallthrough` does not change the program semantics. If you are a maintainer and want to cross-check, compare the codegen. > Have you ever considered the overall cost of the countless > -Wpresume-incompetence flags? Yeah: negative. On the other hand, the overall cost of the countless -fI-am-infallible flags is very noticeable. > Perhaps you pay the power bill for a build farm that produces logs that > no-one reads? Perhaps you've run git bisect, knowing that the compiler > messages are not interesting? Or compiled software in using a language > that generates impenetrable messages? If so, here's a tip: > > # grep CFLAGS /etc/portage/make.conf > CFLAGS="... -Wno-all -Wno-extra ..." > CXXFLAGS="${CFLAGS}" > > Now allow me some pessimism: the hardware upgrades, gigawatt hours and > wait time attributable to obligatory static analyses are a net loss. If you really believe compiler warnings and static analysis are useless and costly, I think there is not much point in continuing the discussion. > No, it's not for me to prove that such patches don't affect code > generation. That's for the patch author and (unfortunately) for reviewers. I was not asking you to prove it. I am stating that proving it is very easy. Cheers, Miguel