compiler warnings (was: Re: [rfc] a few kern.mk and bsd.sys.mk related changes)

[Robert Watson]

On Tue, 31 May 2011, Alexander Best wrote:

> On Mon May 30 11, Dieter BSD wrote:
>> Chris writes:
>>>> Ports need attention. The warnings I get there are frightening.
>>>
>>> I find it comforting that they're just that: warnings.
>>>
>>> How do they frighten you?
>>
>> High quality code does not have any warnings.
>>
>> The most frightening thing is the attitute that "They're just warnings, so 
>> I'll ignore them."  Most compiler warnings should be fatal errors. And a 
>> lot of the warnings that require a -Wwhatever should be on by default.
>
> please keep in mind that -Wfoo does reflect the ideas of the GNU people 
> regarding *proper* code. the warnings themselves are sometimes wrong, 
> because they complain about perfectly correct code. so -Wfoo should not be 
> considered a code verifier, but in fact what it is: a warning flag. 
> sometimes it's correct and indeed reports wrong code, sometimes it is 
> completely wrong.

And, it's also worth remembering that warnings change over time, as the 
compiler changes.  One of the known issues building with clang is that large 
quantities of "warning-free code" under gcc are in fact rife with warnings 
under clang, including the gcc source code itself.  In general, my hope is 
that we can get the FreeBSD base warning-free for a useful set of warnings, 
and on the whole, this is the case.  Pretty much the entire kernel is compiled 
with quite a large number of warning classes enabled, and -Werror set, for 
example.

(One of the other tensions, of course, is the locally maintained vs externally 
maintained tension: fixing warnings in other people's code is useful only if 
you can get them to accept the fixes back -- maintaining large numbers of 
patch sets over time is not sustainable for non-trivial quantifies of code, if 
you're tracking the upstream vendor.  Ports is the worst possible case, where 
maintaining local patches is quite expensive.  In the FreeBSD base we can do 
a lot better, since we can use revision control and automatic merging to help 
us, but it's still an overhead that has to be reasoned about carefully.)

Robert