Re: [boost] Official warnings policy?

Subject: Re: [boost] Official warnings policy?
From: Mateusz Loskot (mateusz_at_[hidden])
Date: 2009-11-04 19:04:44

Emil Dotchevski wrote:
> On Wed, Nov 4, 2009 at 2:05 PM, Bo Persson <bop_at_[hidden]> wrote:
>> Emil Dotchevski wrote:
>>> On Wed, Nov 4, 2009 at 12:12 PM, Vladimir Prus
>>> <vladimir_at_[hidden]> wrote:
>>>> Emil Dotchevski wrote:
>>>>>> Unfortunately,
>>>>>> recent discussion left me with the impression that few folks
>>>>>> care.
>>>>> It is not about caring, once again the argument is about a
>>>>> personal preference: is the ugliness and decreased readability
>>>>> that is often required to silence a warning reasonable.
>>>> I suggest we don't talk in the abstract. Once a specific set of
>>>> warning options, together with -Werror is in place, you can raise
>>>> your concerns
>>>> about any particular warning emitted by any particular compiler,
>>>> and hopefully, some per-warning-kind agreement can be reached.
>>> I agree that the only way warnings can be addressed effectively is
>>> to
>>> use -Werror. On the other hand, the idea that a warning is the same
>>> as
>>> an error challenges my world view. :)
>>>
>>> I understand why you say that we can't talk in the abstract. It's
>>> downright silly not to fix certain "good" warnings and we, as a
>>> community, definitely can agree on a reasonable definition of
>>> "good".
>>>
>>> However this will not address the issue at hand, which is that
>>> people
>>> who use higher warning levels will see tons of warnings. A better
>>> attitude is http://www.zlib.net/zlib_faq.html#faq35.
>> Yes, that's a good attitude. However, how are we going to be sure that
>> the code works, when the compiler says it might not?
> 
> How we are going to be sure that the code works is not a simple
> question, but note that "fixing" a warning simply silences the
> compiler and (ideally) has no effect on the correctness of the code:
> if the code was buggy, it still is.

It is not true.
Fixing a warning is supposed to fix it but not "fix" it.
A warning fix may involve steps like:
- fix bug in code or refactor correct code to improve quality
- if code is perfectly valid, but just  compiler overreacted, silent
  warning with appropriate annotation in code
- refine compiler flags.
- do not touch code, but comment/document the status and give reason why
  no action is to be taken

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org