From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934597AbdBWB0B (ORCPT ); Wed, 22 Feb 2017 20:26:01 -0500 Received: from mail-oi0-f48.google.com ([209.85.218.48]:35898 "EHLO mail-oi0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933325AbdBWBZx (ORCPT ); Wed, 22 Feb 2017 20:25:53 -0500 MIME-Version: 1.0 In-Reply-To: References: <20170221201656.GA52020@beast> From: Linus Torvalds Date: Wed, 22 Feb 2017 17:25:51 -0800 X-Google-Sender-Auth: M70ay2E6dQG9gKZfPVtKhIeAEb0 Message-ID: Subject: Re: [GIT PULL] gcc-plugins updates for v4.11-rc1 To: Kees Cook Cc: Linux Kernel Mailing List , Emese Revfy Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 21, 2017 at 9:07 PM, Kees Cook wrote: > On Tue, Feb 21, 2017 at 6:34 PM, Linus Torvalds > wrote: > >> The crazy "__nocapture()" annotations are too ugly to live, and make >> no sense. They are basically random noise to some very core header >> files. And the "__unverified_nocapture()" ones are worse. > > Is it the naming, or something else? No, it's just that it attaches to a (lot of) really core functions, and makes those prototypes look odd and incomprehensible, and all for a very odd and very limited and specific feature. The plugin simply isn't important enough to warrant that kind of very invasive marking of core functionality. If the syntax was more pleasant, maybe it would be ok. For example, marking the arguments individually in the argument declaration might make it more palatable, ie the difference between (a) standard declaration: void *memcpy(void *dest, const void *src, size_t n); (b) nasty incomprehensible one: void *memcpy(void *dest, const void *src, size_t n) __nocapture(2); (c) possibly more legible one void *memcpy(void *dest, __nocapture const void *src, size_t n); where I'm just randomly throwing out a syntax that I think _might_ be more palatable. Basically, those "numbered argument attributes" are ugly crap, but in the case of things like the printf strings they are ugly shit with very wide applicability and known very meaningful warnings that have saved our arses several times. So for printf, I see those "__attribute__ ((format...))" things, and I think they are a particularly ugly marker, but it's a marker that I think it is worth it, so the ugliness is an acceptable trade-off. For something like "hint if something could be marked __init", the ugliness is stronger (nonstandard fiormat, on even more core functions), and the upside is less. So in the __nocapture case, they are just really ugly (that "negative index means return value" just takes the cake), and they don't even have the major meaning and history that the printf ugliness has had. Linus