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 <b...@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.
_______________________________________________
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
