Re: System headers with clang?

On Tue, 11 Oct 2011, Kevin Oberman wrote:

> On Tue, Oct 11, 2011 at 6:59 AM, Larry Rosenman <ler_at_lerctr.org> wrote:
>> On 10/11/2011 8:51 AM, Dimitry Andric 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. :)
>>>
>>> In any case, isn't lsof's dlsof.h header full of special cases already?
>>> What does it matter to add another one?
>>>
>>> Besides, even if you fix it in the system headers now, at compile time
>>> you cannot be sure if the user has the correct version of them installed
>>> anyway, so you would still have to work around the problem.
>>
>> We will NOT support clang as the compiler for lsof unless the system headers
>> work the same way as gcc's do.
>>
>> Period.
>
> Are asking that clang become bug compatible with gcc or that gcc be
> fixed to present the same errors as clang does? As a casual observer I
> really don't expect either to happen soon. (I suspect gcc being fixed
> SLIGHTLY more likely.)
No, just asking that the same headers not generate ERRORS where gcc
doesn't  Extra Warnings are fine.

the big one here is the _builtin_ffs() one about signed vs unsigned.
>
> By it's very nature lsof does a lot of the sort of kernel interaction
> that is normally considered to be unacceptable and requires lots of
> kludges and hacks to do them. I am simply baffled as to why this issue
> is so different other then that it is dependent on the compiler used
> and not the differences between kernels and kernel interfaces.
It's not.  It's just that this seems(!) to be a trivial issue to fix
for the folks adding/wanting clang to process all ports.


>
> On the other hand, I have not done real kernel programming in
> years...not since I was writing kernel code in assembly for VMS about
> 20 years ago, so maybe I am missing some subtleties about this.
>

-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 512-248-2683                 E-Mail: ler_at_lerctr.org
US Mail: 430 Valona Loop, Round Rock, TX 78681-3893