Date: Thu, 26 Mar 2015 09:19:48 -0500 From: Pedro Giffuni <pfg@FreeBSD.org> To: Tijl Coosemans <tijl@FreeBSD.org>, Bruce Evans <brde@optusnet.com.au> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, gerald@FreeBSD.org Subject: Re: svn commit: r280636 - head/include Message-ID: <55141584.6030600@FreeBSD.org> In-Reply-To: <20150326142052.6789dd50@kalimero.tijl.coosemans.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>
next in thread | previous in thread | raw e-mail | index | archive | help
On 03/26/15 08:20, Tijl Coosemans wrote: > On Thu, 26 Mar 2015 17:37:53 +1100 (EST) Bruce Evans <brde@optusnet.com.au> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?55141584.6030600>