Re: [boost] [new Warnings policy] MS C4180 on theMaintenance Guidelines

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.