Re: System headers with clang?

From: Garrett Cooper <yanegomi_at_gmail.com>
Date: Tue, 11 Oct 2011 12:22:04 -0700
On Tue, Oct 11, 2011 at 11:40 AM, Arnaud Lacombe <lacombar_at_gmail.com> wrote:
> Hi,
>
> On Tue, Oct 11, 2011 at 9:51 AM, Dimitry Andric <dim_at_freebsd.org> wrote:
>> On 2011-10-11 15:31, Larry Rosenman wrote:
>>>
>>> On Tue, 11 Oct 2011, Dimitry Andric wrote:
>>
>> ...
>>>>
>>>> I've attached a fix for the lsof port, which also makes it build on
>>>> 10.0-CURRENT (this was easy to fix here, as lsof uses its own
>>>> hand-rolled configuration script).  Let me know if it works for you.
>>>>
>>> Unless the headers are fixed, Vic Abell (lsof Author) will NOT support it.
>>>
>>> We need to get clang/system headers to allow warning free compilation
>>> just like GCC does.
>>
>> The system headers compile without warning, if you use them as intended
>> (e.g. from the kernel), which lsof obviously doesn't do.  There is no
>> easy workaround here, except by modifying lsof.
>>
>> For example, the warning about KASSERT is because lsof's headers don't
>> include the required headers for this macro.  And gcc is apparently not
>> smart enough to generate warnings for this. :)
>>
> KASSERT() (from `sys/systm.h') is kernel only, any userland code
> seeing it is not using the header properly. I'd be a strong proponent
> of:
>
> #ifdef _KERNEL
> #error "You are NOT meant to define _KERNEL in userland application"
> #endif
>
> So this has nothing to do about smartness, but correctness.

net-snmp suffers from this as well because it pokes around some kernel
structures and data types to gather statistics related to IPv6,
routing, etc in order to fulfill MIB-II compliance. Part of the bits
are present, but not all of them, and I would really like for the need
to muck around in _KERNEL to go away...

Similarly, we have several utilities in base that muck around in
_KERNEL that really shouldn't IMHO.

Thanks,
-Garrett
Received on Tue Oct 11 2011 - 17:22:05 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:19 UTC