On 03/26/15 08:20, Tijl Coosemans wrote:
On Thu, 26 Mar 2015 17:37:53 +1100 (EST) Bruce Evans <b...@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.
_______________________________________________
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
