From owner-svn-src-all@FreeBSD.ORG Fri Mar 27 11:01:48 2015 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 65A8ADE4; Fri, 27 Mar 2015 11:01:48 +0000 (UTC) Received: from mail109.syd.optusnet.com.au (mail109.syd.optusnet.com.au [211.29.132.80]) by mx1.freebsd.org (Postfix) with ESMTP id 23946EC2; Fri, 27 Mar 2015 11:01:47 +0000 (UTC) Received: from c211-30-166-197.carlnfd1.nsw.optusnet.com.au (c211-30-166-197.carlnfd1.nsw.optusnet.com.au [211.30.166.197]) by mail109.syd.optusnet.com.au (Postfix) with ESMTPS id F184BD64414; Fri, 27 Mar 2015 22:01:37 +1100 (AEDT) Date: Fri, 27 Mar 2015 22:01:37 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Tijl Coosemans Subject: Re: svn commit: r280636 - head/include In-Reply-To: <20150326142052.6789dd50@kalimero.tijl.coosemans.org> Message-ID: <20150327214341.E2629@besplex.bde.org> References: <201503252153.t2PLrInc025854@svn.freebsd.org> <20150326130403.W993@besplex.bde.org> <551376D4.4030003@FreeBSD.org> <20150326170535.U2239@besplex.bde.org> <20150326142052.6789dd50@kalimero.tijl.coosemans.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=ZuzUdbLG c=1 sm=1 tr=0 a=KA6XNC2GZCFrdESI5ZmdjQ==:117 a=PO7r1zJSAAAA:8 a=kj9zAlcOel0A:10 a=JzwRw_2MAAAA:8 a=13UMWzg37cEECB_ZgkkA:9 a=CjuIK1q_8ugA:10 Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, Pedro Giffuni , Bruce Evans , svn-src-head@freebsd.org, gerald@freebsd.org X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 11:01:48 -0000 On Thu, 26 Mar 2015, Tijl Coosemans wrote: > On Thu, 26 Mar 2015 17:37:53 +1100 (EST) Bruce Evans wrote: >> On Wed, 25 Mar 2015, Pedro Giffuni wrote: >>> On 03/25/15 21:14, Bruce Evans wrote: >>>> On Wed, 25 Mar 2015, Pedro F. Giffuni wrote: >>>>> Log: >>>>> Temporarily revert 280458. >>>>> >>>>> GCC is still carries an old version of cdefs.h which doesn't >>>>> accept multiple parameters for the nonnull attribute. >>>>> Since this issue probably affects many ports in the tree >>>>> we will revert it for now until gcc gets fixed. >>>> >>>> Note that sys/cdefs.h is supposed to work with any version of >>>> gcc back to gcc-1, and does mostly work back to at least gcc-2.95. >>>> The whole point of sys/cdefs.h is to provide compatibity macros >>>> for old and other non-default compilers. Standard compilers don't >>>> even have __attribute__(()). So no changes in future versions >>>> of gcc will fix the previous commit. >>> >>> cdefs.h still works for all versions of gcc back to gcc-1 AFAICT. >> >> I now remember other bugs in it. I think you put the varargs stuff >> in the non-gcc version. That won't work compilers that don't support >> varargs for macros. Neither will not changing the non-gcc version. I confirmed the complete brokenness of the varargs stuff for the non-C99 case. >> glibc (2.6 at least) avoids using varargs in its __nonnull() macro >> by using the same portable method that is used in many optional >> debugging statements including FreeBSD's KASSERT(). ... > > Maybe introduce a __nonnull_all macro and leave __nonnull varargs-free: > > #define __nonnull(x) __attribute__((__nonnull__(x))) > #define __nonnull_all __attribute__((__nonnull__)) > > Then in the rare cases where multiple arguments must be nonnull but > __nonnull_all doesn't apply you can use multiple __nonnull: > > int f(void *, void *, void *) __nonnull(1) __nonnull(2); Good idea. There aren't many functions that accept null for some pointer args but not others. The multiple __nonnull() method is already used a lot. E.g., in sys/systm.h it is used 11 times. systm.h also gives many examples where __nonnull_all cannot be used. It cannot be used for the strto* family because endptr can be null, or for the copyinstr() family for similar reasons (a value may be returned indirectly but the pointer for this is null if this value is not needed). >> I see. gcc's "fixed" headers cause lots of problems. > > I've complained about this multiple times in the past. The gcc ports > should not install these "fixed" headers. Is this easy to do, and does it work without problems? It might be easier and would be safet to install everything and change the default include path in a way that can be changed back at runtime. Bruce