From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 39993 invoked by alias); 24 Jul 2015 01:31:26 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 39984 invoked by uid 89); 24 Jul 2015 01:31:25 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-pa0-f49.google.com Received: from mail-pa0-f49.google.com (HELO mail-pa0-f49.google.com) (209.85.220.49) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Fri, 24 Jul 2015 01:31:24 +0000 Received: by pabkd10 with SMTP id kd10so5208165pab.2 for ; Thu, 23 Jul 2015 18:31:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-type:content-transfer-encoding; bh=Xe0dZg93XKDpeJc02uiPkW7M9tYLSwesuh9gg7sJqH0=; b=F/Myh9+BmlEVbQrFoBTCGV5iL/DILGcaw0kKc/rpaMSX/Cmdn6Y7w/JT5iPGToUOH0 lSerWHpOwgnH1qzQpzpueIz2nEECBfBqx0zOm0oxHtMyFY0P/ocKrODw7MsBlWes7rm2 AF2nCtNAkLR5xfY0In7GxvzN7BSuJmm/3olWunSzcwlJmExxCuAp+v8bN837ExWBj6ME RbL6+dUAX619zTssXdt7mVM1SgE0vRfoAenQ59FMOLf52kagvsvLTEQyW4ddYsWHkSbl XpKPrVMqp9JBnK1WPr1zw7bc1K60hWUjv+gTeYOFDv36n7HWSzQeYiMLQMqmk+7K/ToY Jz+Q== X-Gm-Message-State: ALoCoQm7E2e1TdqwMfLeXmWqOcYBW2Q2TshINYLYbxBcESJBe455ONi7SuC6w1RISKmLrdt33PPr X-Received: by 10.70.6.161 with SMTP id c1mr24763964pda.76.1437701481984; Thu, 23 Jul 2015 18:31:21 -0700 (PDT) Received: from lemur (c-24-130-240-105.hsd1.ca.comcast.net. [24.130.240.105]) by smtp.gmail.com with ESMTPSA id nx1sm2009769pab.6.2015.07.23.18.31.21 (version=SSLv3 cipher=RC4-SHA bits=128/128); Thu, 23 Jul 2015 18:31:21 -0700 (PDT) Date: Fri, 24 Jul 2015 05:13:00 -0000 From: Martin Uecker To: Marek Polacek Cc: GCC Patches Subject: Re: [RFC, PATCH] nonzero attribute, static array parameter Message-ID: <20150723183117.1d4104f0@lemur> In-Reply-To: <20150515133843.GR27320@redhat.com> References: <20150509094223.300601b8@lemur> <20150515133843.GR27320@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-SW-Source: 2015-07/txt/msg01995.txt.bz2 Hi Marek, sorry for taking so long to respond. Fri, 15 May 2015 15:38:43 +0200 Marek Polacek : > On Sat, May 09, 2015 at 09:42:23AM -0700, Martin Uecker wrote: > > here is a tentative patch to implement a new attribute nonzero, > > which is similar to nonnull, but is not a function attribute > > but a type attribute. > > > > One reason is that nonnull is awkward to use. For this reason, > > clang allows the use of nonnull in function parameters, but this > > is incompatible with old and current use of this attribute in gcc > > (though in a rather obscure use case). > > See: https://gcc.gnu.org/ml/gcc/2015-05/msg00077.html > > Sorry, I quite fail to see how such an attribute would be useful. First of all, it makes it much simpler to implement the desired warnings and ubsan checks when passing NULL as an array parameters with 'static'. It avoids implementing all this argument walking code which is needed for nonnull. If we do not want a nonzero attribute, could we then consider an internal attribute (e.g. "non zero")? > It seems that the nonzero warning can only ever trigger when used > on function parameters or on a return value, much as the nonnull / > returns_nonnull attributes. So far. But in the future this could be extended to other cases where it makes sense. > The difference is that you can use > the nonzero attribute on a particular function parameter, but the > nonnull attribute has this ability as well: > > __attribute__ ((nonnull (1))) void foo (int *, int *); > void > bar (void) > { > foo (0, 0); > } I know. But this is ugly, cumbersome, and fragile, and some uses are incompatible with clang. That nonnull is mis-designed has been pointed out before: https://gcc.gnu.org/ml/gcc/2006-04/msg00551.html > Unlike nonnull, nonzero attribute can be attached to a typedef, but > it doesn't seem to buy you anything you couldn't do with the nonnull / > returns_nonnull attributes. It is much more expressive. A nonnull pointer _type_ seems really useful to me. Many programming languages have something like this. > The nonzero attribute can appertain even to integer types, not only > pointer types. Can you give an example where this would come in handy? > It doesn't seem too useful to me. One example: void assert(__attribute__((nonzero)) int i); would give a warning if it is already known at compile time that the expression is zero. > > +void foo1(int x[__attribute__((nonzero))]); > > This looks weird, It does look weird. But this is already documented in this way: https://gcc.gnu.org/onlinedocs/gcc/Attribute-Syntax.html#Attribute-Syntax The use of 'const' and 'static' in an array declarator as defined by ISO C99 is already weird. > the placement of the nonzero attribute here suggests > that the array should have at least zero elements (the same that > int x[static 0] does), but in fact it checks that the pointer passed > to foo1 is non-NULL, i.e. something that could be easily achieved > with the nonnull attribute. In many case it would be much nicer to be able to declare a nonzero type and use it in interfaces instead of having to add __attribute__((nonnull(1,2,5,8))) with exactly the right numbers to a lot of prototypes. > > The other reason is that a nonzero type attribute is conceptually > > much simpler and at the same time more general than the existing > > nonnull and nonnull_return function attributes (and could replace > > both), e.g. we can define non-zero types and diagnose all stores > > of known constant 0 to variables of this type, use this for > > computing better value ranges, etc. > > Why would that be useful? What makes integer 0 special? 0 is special in many ways. In particular it represents false in an if clause. Also, why artificially restrict it to pointers when it is trivial to make it work for integers too? Martin