svn commit: r325954 - in head: . share/mk sys/conf usr.sbin/config

[Pedro Giffuni]

On 11/19/17 05:05, Bruce Evans wrote:
> On Sat, 18 Nov 2017, Warner Losh wrote:
>
>> On Sat, Nov 18, 2017 at 3:42 AM, Bruce Evans <brde at optusnet.com.au> 
>> wrote:
>>
>>> since it flags all c99 and newer usages as syntax errors. We've been
>>>>>>
>>>>>
>>> This shouldn't break use of lint on K&R or C90 sources. But types.h is
>>> broken.  It no longer supports K&R, C90, or most other things that are
>>> supposed to be controlled by the visibility ifdefs in it.
>>
>> Thanks for this insightful analysis. I've clipped the rest of it, 
>> which is
>> more of the same. It can't support the new C compiler construct, and 
>> we've
>> managed to break the old ones. Plus it gives lots of warnings that 
>> aren't
>
> Lint is just the messenger (until its annotations like NOTREACHED are 
> also
> removed).  It can support old C compiler constructs like it used to,
> including pre-standard ones that new C compilers/checks might not 
> support.
>

FWIW, I don't think we should remove the LINT annotations: they are 
recognized by Coverity.
I don't see us adding them in new code but removing them would trigger a 
bunch of false positives in Coverity.

>> useful and doesn't understand several of the idioms we've started using
>> heavily in the kernel (such as forward struct declaration). Since 
>> many of
>> these problems are in the system kernel headers, the break all 
>> non-trivial
>> uses of lint.
>>
>> None of these things are ever going to be fixed. It's quite likely the
>
> We are never going to fix feature test macros like _POSIX_SOURCE? Then
> removing support for them would give much simpler sources.
>

I think the point here is that having xlint was never a step towards 
fixing such issues. It was also poorly maintained: I recall being the 
last one to look at merging changes from NetBSD, so I know how bad it was.

It would be nice to have a replacement, but a quick look doesn't show 
anything interesting.

Solaris/illumos has a lint utility but I am not sure the illumos guys 
find that too useful either.
I guess it would be useful for upstreaming stuff to openZFS though so a 
port is welcome.

>> kernel will never again compile on anything older than a c99 compiler.
>> While we have a lot of ifdefs to attempt to support older compilers, 
>> it's
>> almost all certainly bit-rotted from lack of use.
>
> The headers and libraries (non-source parts) should not be limited by the
> language used to compile the kernel.  Pascal is not supported, but old
> variants of C require only a small amount of code relative to new 
> variants,
> so should remain supported.
>
> Kernels don't actually compile with a C99 compiler.  They need -std=gnu99
> plus lots of underscores to use extensions.  The kernel is misconfigured
> with -std=isomumble:1999 -fms-extensions and only compiles because this
> doesn't give strict C99 (+ ms extensions but no gnu extensions). Userland
> is configured correctly with -std=gnu99.
>

This brings back the older discussion about being realistic and 
deprecating older compilers that no one uses any more. Yes, we should 
avoid breaking existing stuff (however old) in ports but no one is 
expecting to build modern FreeBSD with gcc 3.4 or even gcc 4.1. We did 
what we could with gcc 4.2.1 but it's time is also over.

All IMHO, of course.

Pedro.