Re: [boost] Official warnings policy?

Subject: Re: [boost] Official warnings policy?
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2009-11-04 18:02:14

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.

(Qualifying the above with "ideally" is necessary because sometimes
fixing a lame warning on one platform could also silence a valid
warning on another platform.)

Emil Dotchevski
Reverge Studios, Inc.
http://www.revergestudios.com/reblog/index.php?n=ReCode