On Mon, 20 May 2013, Stefan Farfeleder wrote:
On Mon, May 20, 2013 at 01:06:50PM +0200, Ed Schouten wrote:
Hi Stefan,
2013/5/19 Stefan Farfeleder <stef...@freebsd.org>:
Shouldn't we fix lint and our headers to use a different macro name? One
starting with __?
Fixing lint: yes. Changing our macros to use a different name: no.
The reason why we had __volatile, __inline, etc. in the first place,
was because adding definitions for volatile and inline directly would
be against the standard, as these words can be used freely in <C99.
volatile was standard in C90.
C11 only added keywords starting with _[A-Z], which is reserved by all
the older standards, meaning we are completely free to define them in
any way we like.
Except when C11 or the compiler defines them.
This specific breakage was unrelated to the naming of the keyword. The
breakage existed, because existing tools do a build with -Dlint set.
Because we use _Thread_local in our own header files already
(runetype.h, I think), this caused a variable declared in a header
file to be of the wrong kind (TLS vs non-TLS).
Isn't this a bug in the tools too (if they define lint to get linting)?
lint itself predefines lint, so defining it in source code seems wrong.
Since it is not reserved, they can define it for their own purposes,
but then it might interfere with actually running lint.
In my opinion we should not add __[a-z] definitions for things that
are part of C11. Doing this only makes our code less easily exportable
to other systems.
Only using reserved words (including new ones in C11) in applications gives
unportability. Ones like __FBSDID() that are meant to be used shouldn't
exist.
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.
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.
Bruce
_______________________________________________
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
