svn commit: r250806 - head/sys/sys

Bruce Evans brde at optusnet.com.au
Mon May 20 15:36:01 UTC 2013


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 <stefanf at 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


More information about the svn-src-all mailing list