svn commit: r280636 - head/include

[Pedro Giffuni]

On 03/26/15 08:20, Tijl Coosemans wrote:
> On Thu, 26 Mar 2015 17:37:53 +1100 (EST) Bruce Evans <brde at 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.