On Tue, May 21, 2013 at 01:15:11AM +1000, Bruce Evans wrote: > On Mon, 20 May 2013, Stefan Farfeleder wrote: > > > I think you misunderstood what I meant. We now have quiet a few > > occurrences of `#ifdef lint' or equivalent in /usr/include. I think those > > should be changed to `#ifdef __lint' to allow application code to do > > > > #define lint foo > > #include <header.h> > > > > which is perfectly fine POSIX code (at least to my knowledge) and should > > not change the behaviour of the included header. > > lint actually predefines __LINT__, not __lint.
__LINT__ is fine with me. I didn't bother to read lint's source, but the man page states: "The lint utility runs the C preprocessor as its first phase, with the preprocessor symbol “lint” defined to allow certain questionable code to be altered or skipped by lint. Therefore, this symbol should be thought of as a reserved word for all code that is to be checked by lint." > Of course it is a bug that system headers depend on symbols in the > application namespace like lint. My version never had the lint ifdef(s) > in sys/cdefs.h. I don't like them for other reasons. They results in > lint checking different source code to what the compiler sees. FreeBSD's > lint barely supports C90, but C99 features like C99 initializers are now > used extensively, at least in the kernel. Use of features like this > can't be hidden from lint using a few ifdefs in headers. Since nobody wants to update lint to recent C standards, maybe it's time to remove it? Stefan _______________________________________________ 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"