Subject: Re: [boost] [new Warnings policy] MS C4180 on theMaintenance Guidelines
From: John Maddock (john_at_[hidden])
Date: 2009-11-20 11:17:15
>> >> I propose to replace all of the existing
>> >> warnings guidelines in the Wiki with the following: "No warnings
>> >> should be emitted by Boost code. Use your best judgment to
>> >> either fix or suppress the warning."
>> >
>> > I like the simplicity of this statement of purpose, but
>> > there's value in
>> > educating developers on how to judge whether to fix or suppress a
>> > warning and in the information on how to deal with specific warnings
>> > and compiler vagaries.
>>
>> If I understand correctly, you are concerned with the possibility of
>> developers suppressing warnings as opposed to "fixing them properly."
>>
>> My wording, which is indeed intended to be complete, specifically
>> seeks to avoid such differentiation. Rather than arguing what is right
>> and what is wrong, we should consider the simple fact that if a Boost
>> developer suppresses a warning in a particular library, there are no
>> reasonable grounds to require the warning to be enabled and the code
>> "fixed".
>
> You seem to make two assumptions: warnings are nuisances that should be
> ignored and all Boost authors and maintainers have sufficient knowledge to
> judge whether a warning should be ignored (suppressed). Neither
> assumption is appropriate. For the guideline to be useful, more is
> needed.
>
> Warnings often indicate real problems. Sometimes they only manifest on a
> particular platform, revealing a portability issue. Sometimes they
> indicate that the code doesn't account for a runtime condition, like
> overflow, which the warning can only suggest as a possibility.
> Suppressing a warning without altering code may simply mask a problem.
> The right approach is to determine why the warning occurs, decide whether
> it is correct in the context, and if so, apply appropriate remediation.
> If the warning is not correct in the context, only then should it be
> suppressed. Your statement doesn't say even that much.
>
> Because developers don't have the same knowledge, even among Boost
> developers, Boost should amass information to help them know when a
> warning is significant and not. That information can show cases in which
> a warning is legitimate and when it isn't. For the former, there can be
> help to understand how to change the code portably to account for the
> problem revealed by the warning. For the latter, there can be information
> on how to suppress the warning in a portable way.
>
> I know that changing code can lead to bugs. Thus, changing code to
> eliminate a warning might create a bug. That's unfortunate. From a
> maintenance standpoint, however, I'd prefer to see altered code to a glob
> of preprocessor and pragma line noise that suppresses a warning in the
> unchanged code. Testing will reveal the bug. If it doesn't, the testing
> is insufficient. If the bug appears on an untested platform, then more
> testers are needed to be able to detect such bugs in the future.
Very elegantly put, and sums up very much how I feel as well.
To put it another way, for some users, any warning *is* a bug.
John.