From owner-svn-src-all@FreeBSD.ORG Thu Mar 26 06:38:03 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 76755180; Thu, 26 Mar 2015 06:38:03 +0000 (UTC) Received: from mail104.syd.optusnet.com.au (mail104.syd.optusnet.com.au [211.29.132.246]) by mx1.freebsd.org (Postfix) with ESMTP id 37C175F4; Thu, 26 Mar 2015 06:38:03 +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 mail104.syd.optusnet.com.au (Postfix) with ESMTPS id 881654249AD; Thu, 26 Mar 2015 17:37:54 +1100 (AEDT) Date: Thu, 26 Mar 2015 17:37:53 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Pedro Giffuni Subject: Re: svn commit: r280636 - head/include In-Reply-To: <551376D4.4030003@FreeBSD.org> Message-ID: <20150326170535.U2239@besplex.bde.org> References: <201503252153.t2PLrInc025854@svn.freebsd.org> <20150326130403.W993@besplex.bde.org> <551376D4.4030003@FreeBSD.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=aE7OyBw8yOmdTJHGsokA:9 a=CjuIK1q_8ugA:10 Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Bruce Evans 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: Thu, 26 Mar 2015 06:38:03 -0000 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. 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(). (KASSERT() is broken as designed. It never needed this since it wasn't implmented until several years after C99 standardized varargs for macros.) The macro takes a single arg consisting of a normal list of args enclosed in parentheses. The extra parentheses are not passed to the __attribute__() list. All invocations of the macro must be ugly to supply the parantheses. The parentheses give a large syntactic difference, so the ugliness cannot be fixed easily by switching to varargs macros. For KASSERT(), there would be about 7500 in /usr/src lines to clean up. For __nonnull(), there would be only about lines 160 in /usr/src to change. Mostly __nonnull(1) -> __nonnull((1)). But __nonnull() is more likely to be (mis)used in ports. > The reason why I had to revert the change is actually a systematic > bug in gcc: during it's build process gcc generates a new cdefs.h > from our headers. Attempting to use an older gcc from ports > that was build with the broken mono-parameter __nonnull() ended > up causing breakage in any code using signal.h or pthreads.h. I see. gcc's "fixed" headers cause lots of problems. > The lesson here is to update gcc every time cdefs.h is updated Whenever a "fixed" header is changed. Bruce