From owner-svn-src-all@FreeBSD.ORG Thu Mar 26 14:25:25 2015 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9A97BB32 for ; Thu, 26 Mar 2015 14:25:25 +0000 (UTC) Received: from nm31-vm6.bullet.mail.bf1.yahoo.com (nm31-vm6.bullet.mail.bf1.yahoo.com [72.30.239.14]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4E6EDFC8 for ; Thu, 26 Mar 2015 14:25:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1427379587; bh=I1/8+vU7azXSOPWkj37nXHkSj7rGpyDnmIxzGFZYyLs=; h=Date:From:To:CC:Subject:References:In-Reply-To:From:Subject; b=rioYwe9WloZS644vuwNbAOVph0amgv3cUtNVlsWGEDHwg73aP0V+QmXyBmQLMOuNJWzhTlgjWgEzjvSnnVIISEs4AgxUJTziff9N1abo/H3u6GVh1KtejVYmAVFYhuYqnGpJe8S5UZFWgmRH/58+xY+8aI2CVTujfnVPcKQr5N+AyBCl1NS2DIgEB2Fw/Dp5iToBlSOZfunn9bW5l9cV4eJzpgWgPmIrKaZWR3eYayMmFr33nqOAG/QFuQAyjnoxVwY5PxJoUtoYxFBpM7bgu+WM0MRo8oXHo6Xdc849AN6sJbimr/Gv7Jaoj8PRVa92bBH+e0hy+axWr2qbrIunRg== Received: from [98.139.170.181] by nm31.bullet.mail.bf1.yahoo.com with NNFMP; 26 Mar 2015 14:19:47 -0000 Received: from [98.139.211.201] by tm24.bullet.mail.bf1.yahoo.com with NNFMP; 26 Mar 2015 14:19:47 -0000 Received: from [127.0.0.1] by smtp210.mail.bf1.yahoo.com with NNFMP; 26 Mar 2015 14:19:47 -0000 X-Yahoo-Newman-Id: 206948.76965.bm@smtp210.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: glBnX_oVM1lEqEV9o.sQ6ZaKe3PKFCkg2cMp8SioFdK5Zbz lFKwhKcaZnaV7RNXW6YlLoGKnwWKm1PwKFGM3FK_94mP9fIMtFbhBffOl4Fs slBG166zyXg0r6zIgjWRRTGa8jM7_66Z.ZWEsKNDf2f_sJih0iJnu0zl2ehS tVcQaGT9NUf3r6Nb6XLsqwHuKOzGUK2uuVwYDH6HaCcZMuVchbItqeUEZYla Is5n1.FP1RS9xvkSgfPK0ArL4u3IaTlotB4Il76jnK1QDrSjHyzxSPccSM5r 7T3gCmyOzWiYaVeng_qbcktDTIp_aEIipjH0h3n9jo8zPA6QPLgeSMLnFzF2 1jthkw5YzR.46G.9MnSoxQbUtepuJUlJSc142_KOemYGRMMsquMKRYYeIo.9 ekO4CFxXodzydXUrVnEUJ3nNpfSGkGBss0rhEvPZjVu2uTl9iy0.GZUuKbnS MlIa_VsSpHMMxeY82H0qr.JYBqaQF4lVkvMjP3HieTJ9ZyT23bKi3KvdMNhS 28buJsYMbaepD0Cq3Klo94Y___Q-- X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf Message-ID: <55141584.6030600@FreeBSD.org> Date: Thu, 26 Mar 2015 09:19:48 -0500 From: Pedro Giffuni User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Tijl Coosemans , Bruce Evans Subject: Re: svn commit: r280636 - head/include 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> In-Reply-To: <20150326142052.6789dd50@kalimero.tijl.coosemans.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@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: Thu, 26 Mar 2015 14:25:25 -0000 On 03/26/15 08:20, Tijl Coosemans wrote: > On Thu, 26 Mar 2015 17:37:53 +1100 (EST) Bruce Evans wrote: >> --- snip --- >> >> 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. > 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); > the __all extension takes more space than the extra parenthesis. I honestly see no reason to cope with pre-C99 compilers. The base compilers accept the standard varargs fine, for previous compilers we will ignore non standard varargs and use the null implementation. >>> 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. > I've complained about this multiple times in the past. The gcc ports > should not install these "fixed" headers. Yes it is a gcc bug. And I already forwarded the issue to the gcc maintainer. > Pedro, by reverting this commit you only allow this problem to persist, > so please reapply it. You also shouldn't wait weeks before applying > the next commit. No amount of waiting is enough. There will always be > users bitten by it. The problem is in the ports. It needs to be fixed > there. If you receive any problem reports that are caused by this gcc > problem, forward them to the gcc port maintainer. > There's no good reason not to be nice with our developers. I will update cdefs with a week anticipation and point them to update gcc after the header changes. I will MFC the cdefs updates but not the header changes. Pedro.