Received: by 10.223.164.202 with SMTP id h10csp3387877wrb; Tue, 28 Nov 2017 10:28:06 -0800 (PST) X-Google-Smtp-Source: AGs4zMb3cRmf8xsUG0DlFeWe30A3QDHAGo3vtPjozDUIXgqLgrGgaXyCGZhfnSHhIZQ915qll8n6 X-Received: by 10.98.144.88 with SMTP id a85mr51755pfe.127.1511893685935; Tue, 28 Nov 2017 10:28:05 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1511893685; cv=none; d=google.com; s=arc-20160816; b=G8AEk6iftpYdmjjdLZqb7LAOEZqEfAgrbXjtz3u17aOubqUypUAgjf8bAKEcGyiiDD gE9PTSz/3zSlq2Xgri0hKhF7VTrEtKrjKq/GmNewEvbNh23gmbrI2YL5vFOrylt/DIFw BPlbtdAmB/b1VyQwQpx2GLSAy6xTwHSucd2P/KcMuJT2Z8ivJWePoHAnZWx24OlbyfxW ULcf8+zbjpXfh8PbE6qK0SAuReTw8HUytQLPS+sgqRLC9AzllgV9E7290YoUQwpfDoQX opCawLhdhcYURAU+MwyGOkQjWfn3ui/cv6O/v5e9nr0XmWy+gbG8PMeN+3CPUlA7oAZz /n0w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date :arc-authentication-results; bh=hV/ky//8FvLIdg8o4z4e3Ua8IU3m0m9FktaE1s6XoEE=; b=AQ/oAvkm3CExBFc1/+AMOdntEaF1jARCJGmmPbJbmRpan0SdtQb/4CK+GybB0w8I3/ WcXUB/+2n97JRXntf05Vc0PlMfFXcCgDXwYGy5JUkCNuzWieelxjg/RYfPcKnYb/fMLn 7X59pOgNdVVYz8dkj919KUWk+ZSE+AtVL6PVF9038ufbO3wU/M7KQ/+TFh6ElbLHcqy7 hhynAhTFMcTWhouFxQu3sJy8KadL0KaZfVtyWbSVyQmP9fU706O73/fv8HLztAhs6Kxz F58iaK322htBbH2V4DW+89eC2DA/UNzIkfA2gaMcPg2cuaq/YZ2flb/71MV2Tae6xOWf PCyg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b126si24828232pgc.595.2017.11.28.10.27.53; Tue, 28 Nov 2017 10:28:05 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752347AbdK1S1S (ORCPT + 78 others); Tue, 28 Nov 2017 13:27:18 -0500 Received: from Galois.linutronix.de ([146.0.238.70]:35057 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751796AbdK1S1R (ORCPT ); Tue, 28 Nov 2017 13:27:17 -0500 Received: from p4fea5f09.dip0.t-ipconnect.de ([79.234.95.9] helo=nanos) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1eJkZt-00054b-4F; Tue, 28 Nov 2017 19:25:53 +0100 Date: Tue, 28 Nov 2017 19:27:00 +0100 (CET) From: Thomas Gleixner To: "Gustavo A. R. Silva" cc: Ingo Molnar , "H. Peter Anvin" , x86@kernel.org, linux-kernel@vger.kernel.org, Kees Cook Subject: Re: [PATCH] x86/syscalls: Mark expected switch fall-throughs In-Reply-To: <20171128122235.Horde.vFP-9ZfAP0f9BFNePB8Z8xi@gator4166.hostgator.com> Message-ID: References: <20171127235253.GA20384@embeddedor.com> <20171128120512.Horde.1mz61Up1PsNtyHbrjWmK8L7@gator4166.hostgator.com> <20171128122235.Horde.vFP-9ZfAP0f9BFNePB8Z8xi@gator4166.hostgator.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 28 Nov 2017, Gustavo A. R. Silva wrote: > Quoting Thomas Gleixner : > > > To be honest, such comments annoy me during a code review especially when > > > the fallthrough is so obvious as in this case. There might be cases where > > > its worth to document because it's non obvious, but documenting the > > > obvious > > > just for the sake of documenting it is just wrong. > > > > I understand that and I agree that in this particular case it is just obvious. > The thing is that if we want to benefit from having the compiler help us to > spot these kind of issues before committing our code, we have to address every > place in the whole code-base. > > > And _IF_ at all then you want a fixed macro for this and not a comment > > which will be formatted as people see it fit. > > > > GCC supports: __attribute__ ((fallthrough)) which we can wrap into a macro, > > e.g. falltrough() > > > > That'd be useful, but adding all these comments and then having to chase a > > gazillion of warning instances to figure out whether there is a comment or > > not is just backwards. > > > > I have run into this before and people find what you suggest even uglier. It's not about ugly. It's about _USEFULL_. The comments are ugly AND completely useless for the compiler and they are going to be malformatted so checker tools can't differentiate the false positives. The macro, in which more or less ugly form written, is both documentation and helps the compiler NOT to emit the same crap over and over. Thanks, tglx From 1585335141593876673@xxx Tue Nov 28 18:23:27 +0000 2017 X-GM-THRID: 1585265423856272058 X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread