From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 53213 invoked by alias); 15 May 2015 13:39:02 -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 53198 invoked by uid 89); 15 May 2015 13:39:01 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 15 May 2015 13:39:00 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t4FDcsA8029654 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 15 May 2015 09:38:55 -0400 Received: from redhat.com (ovpn-204-66.brq.redhat.com [10.40.204.66]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t4FDcjE7016520 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 15 May 2015 09:38:49 -0400 Date: Fri, 15 May 2015 13:45:00 -0000 From: Marek Polacek To: Martin Uecker Cc: GCC Patches , Joseph Myers , Manuel =?iso-8859-1?B?TPNwZXotSWLh8WV6?= , Jason Merrill , Jakub Jelinek Subject: Re: [RFC, PATCH] nonzero attribute, static array parameter Message-ID: <20150515133843.GR27320@redhat.com> References: <20150509094223.300601b8@lemur> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150509094223.300601b8@lemur> User-Agent: Mutt/1.5.23 (2014-03-12) X-SW-Source: 2015-05/txt/msg01407.txt.bz2 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. 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. 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); } 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. 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. +void foo1(int x[__attribute__((nonzero))]); This looks 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. > 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? Marek