Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp151630pxu; Wed, 25 Nov 2020 15:58:57 -0800 (PST) X-Google-Smtp-Source: ABdhPJydYpcKTOnwsomm3qO4ddAnlqHRtnCjF0UAkUf2VMcFIELjYoGXGXEpu3C2r5lQcbgnte1U X-Received: by 2002:aa7:db53:: with SMTP id n19mr111712edt.73.1606348737570; Wed, 25 Nov 2020 15:58:57 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1606348737; cv=none; d=google.com; s=arc-20160816; b=DapIBcpLsnDdrv3MD2FI/JB9m5DEKBbTUMdtr2MFZPq1g/7vufIteqxWsTw4OiR7LE luYbz3PLoKZ8FGz/0HrxkX8lpfFfstc7zK0NVwI2/rSUeYwRkfuQScuSBgDZAn2l6lPW urf4tnqFn4ZOej8E5GvEwFmBysXwXvxmKgd8V846siIxZHNcRqaiRAEGurHcYJWA1m8v cScmD5FAeUVKmsGET0l9+bjNgPhi5nH30Zi2DB5yxunfP3zV23/9oaEV2nm2QNnTBE/n PD4NXECxvyAd5Hwdo+N5/27nKeGyhU2d3ygKZyS8gs7xP0j0u+3eBO2UrJZV89ix6ol2 BO9A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:references:message-id:in-reply-to :subject:cc:to:from:date; bh=mod24iPlOIRytkgTlGHL105Ak8dcfCT40D8baLqdx/s=; b=QUm/uOJjLhsL/tJ2Q+Rym0W+rToctVw+wzfGUmbA8F5FV5F/rF20bknpsZDNdpUu1l 5ZTzWTex5arvfpTnp5ldE7kvl7mLC6jT2Ts+zZDigbXh50/bh8S5dutDph+uWaNuj2x2 LT5KCLkg9AB/LMBq3EliYkUdFuDYfaiX/kvH4A00CUMr9QBdKkSZC3C/J1hEfBue8/4D Ae7NIRYTK1YputYQBgLGBQ2Sjwxna5vyUHO7KO8dOodOSjedvh3PqUnJ1lkaC1hN6hDj B5Z6/X0z/vCVCXLliPqQTZL96eZOfTQZeZNII1fNJCvC+ZgOILdcNjZ4DpdZgxbGx3oV o+Xg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id s19si1489320ejz.621.2020.11.25.15.58.26; Wed, 25 Nov 2020 15:58:57 -0800 (PST) Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730171AbgKYXWC (ORCPT + 99 others); Wed, 25 Nov 2020 18:22:02 -0500 Received: from kvm5.telegraphics.com.au ([98.124.60.144]:41590 "EHLO kvm5.telegraphics.com.au" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729779AbgKYXWB (ORCPT ); Wed, 25 Nov 2020 18:22:01 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by kvm5.telegraphics.com.au (Postfix) with ESMTP id 414EA2A490; Wed, 25 Nov 2020 18:21:54 -0500 (EST) Date: Thu, 26 Nov 2020 10:21:54 +1100 (AEDT) From: Finn Thain To: Nick Desaulniers cc: James Bottomley , Kees Cook , "Gustavo A. R. Silva" , Joe Perches , Jakub Kicinski , 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 , LKML , Nathan Chancellor , 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, linux-scsi@vger.kernel.org, linux-rdma@vger.kernel.org, oss-drivers@netronome.com, bridge@lists.linux-foundation.org, linux-security-module@vger.kernel.org, amd-gfx list , 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@vger.kernel.org, Miguel Ojeda , tipc-discussion@lists.sourceforge.net, linux-ext4@vger.kernel.org, linux-media@vger.kernel.org, linux-watchdog@vger.kernel.org, selinux@vger.kernel.org, linux-arm-msm , 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, "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" , linux-nfs@vger.kernel.org, GR-Linux-NIC-Dev@marvell.com, Linux Memory Management List , Network Development , linux-decnet-user@lists.sourceforge.net, linux-mmc@vger.kernel.org, Linux-Renesas , linux-sctp@vger.kernel.org, linux-usb@vger.kernel.org, netfilter-devel@vger.kernel.org, "open list:HARDWARE RANDOM NUMBER GENERATOR CORE" , patches@opensource.cirrus.com, linux-integrity@vger.kernel.org, target-devel@vger.kernel.org, linux-hardening@vger.kernel.org, Jonathan Cameron , Greg KH Subject: Re: [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang In-Reply-To: Message-ID: References: <202011201129.B13FDB3C@keescook> <20201120115142.292999b2@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <202011220816.8B6591A@keescook> <9b57fd4914b46f38d54087d75e072d6e947cb56d.camel@HansenPartnership.com> <0147972a72bc13f3629de8a32dee6f1f308994b5.camel@HansenPartnership.com> <20201123130348.GA3119@embeddedor> <8f5611bb015e044fa1c0a48147293923c2d904e4.camel@HansenPartnership.com> <202011241327.BB28F12F6@keescook> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org On Wed, 25 Nov 2020, Nick Desaulniers wrote: > On Wed, Nov 25, 2020 at 1:33 PM Finn Thain > wrote: > > > > Or do you think that a codebase can somehow satisfy multiple checkers > > and their divergent interpretations of the language spec? > > Have we found any cases yet that are divergent? I don't think so. There are many implementations, so I think you are guaranteed to find more divergence if you look. That's because the spec is full of language like this: "implementations are encouraged not to emit a diagnostic" and "implementations are encouraged to issue a diagnostic". Some implementations will decide to not emit (under the premise that vast amounts of existing code would have to get patched until the compiler goes quiet) whereas other implementations will decide to emit (under the premise that the author is doing the checking and not the janitor or the packager). > It sounds to me like GCC's cases it warns for is a subset of Clang's. > Having additional coverage with Clang then should ensure coverage for > both. > If that claim were true, the solution would be simple. (It's not.) For the benefit of projects that enable -Werror and projects that nominated gcc as their preferred compiler, clang would simply need a flag to enable conformance with gcc by suppressing those additional warnings that clang would normally produce. This simple solution is, of course, completely unworkable, since it would force clang to copy some portion of gcc's logic (rewritten under LLVM's unique license) and then to track future changes to that portion of gcc indefinitely.