Re: System headers with clang?

Am 11.10.2011 15:31, schrieb Larry Rosenman:
> On Tue, 11 Oct 2011, Dimitry Andric wrote:
> 
>> On 2011-10-09 19:32, Larry Rosenman wrote:
>>> I had gotten a PR about sysutils/lsof not compiling with clang.  I had
>>> Vic Abell check it out, and the problem is NOT with lsof per se, but
>>> with the system headers.
>>>
>>> Is there a project afoot to update the system headers to make them clang
>>> compilable?
>>
>> The problem isn't that clang can't compile the system headers, but
>> normally these don't get included from userspace.  And they certainly
>> won't work as expected when you define _KERNEL in userspace, as the lsof
>> port foolishly does.  It probably can't be avoided in such a tool,
>> though.


Point #1: some of the headers have special requirements, like inclusion
order, or thereabouts.  Since these are kernel headers, you need to
abide by their rules.

Violated here:

>>
>>
>> ...
>>> In file included from ckkv.c:43:
>>> In file included from ./../lsof.h:195:
>>> In file included from ./../dlsof.h:190:
>>> In file included from /usr/src/sys/ufs/ufs/ufsmount.h:36:
>>> /usr/src/sys/sys/buf.h:388:2: warning: implicit declaration of
>>> function 'KASSERT' is invalid in C99
>>> [-Wimplicit-function-declaration]
>>>           KASSERT(bp->b_bufobj != NULL, ("bwrite: no bufobj bp=%p",
>>> bp));
>>>           ^

I *suppose* KASSERT is meant as a macro, but even if it's not, ...

>>> /usr/src/sys/sys/buf.h:388:33: warning: expression result unused
>>> [-Wunused-value]
>>>           KASSERT(bp->b_bufobj != NULL, ("bwrite: no bufobj bp=%p",
>>> bp));
>>>                                          ^~~~~~~~~~~~~~~~~~~~~~~~~
>>
>> These are more or less harmless warnings, as long as nobody calls a
>> function that uses KASSERT.  They occur because lsof's headers don't
>> include <sys/param.h> and <sys/systm.h> before <sys/ufs/ufs/ufsmount.h>.

...I'd say that's an lsof, rather than kernel or clang, bug.

>>
>> ...
>>> In file included from ckkv.c:43:
>>> In file included from ./../lsof.h:195:
>>> In file included from ./../dlsof.h:432:
>>> In file included from /usr/include/string.h:45:
>>> /usr/include/strings.h:47:6: error: conflicting types for
>>> '__builtin_ffs'
>>> int      ffs(int) __pure2;
>>>            ^
>>> /usr/include/machine/cpufunc.h:140:24: note: expanded from:
>>> #define        ffs(x)  __builtin_ffs(x)
>>>                          ^
>>> /usr/include/strings.h:47:6: note: '__builtin_ffs' is a builtin with
>>> type 'int (unsigned int)'
>>
>> This is because the amd64 system headers redefine ffs to __builtin_ffs,
>> after which it conflicts with the declaration in /usr/include/strings.h.
>> On i386, ffs is not redefined, but I have no idea why.

Arguably __builtin_ffs() is inconsistently defined if it expects an
unsigned int argument.  POSIX demands int for ffs()'s argument.

The builtin should match that.  I can't currently point fingers at the
culprit for lack of research/information.

Chances are -fno-builtin helps.

> We need to get clang/system headers to allow warning free compilation
> just like GCC does.

Then make sure that your code is correct.  NOTE: GCC defaults to C89
with GNU extensions, clang defaults to C99.  To know how GCC treats your
code in C99 mode, try gcc -pedantic-error -std=c99 (or possibly
-pedantic without -error suffix if there are bogus warnings) and see if
it's really clang -- or rather the code...

You can override options for either in the port, see
http://wiki.freebsd.org/PortsAndClang#Problems_with_fixes and look for
USE_CSTD.

It won't make your (Vic's) code future proof, but may help for the nonce
- or not.

Of course Vic is free in writing arbitrarily nonportable code, but
before he or you go(es) pointing fingers, check if you're using kernel
headers properly and requesting compilation in the right language, and
if the code is actually conformant.