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

Subject: Re: [boost] [new Warnings policy] MS C4180 on the Maintenance Guidelines
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2009-11-20 09:33:51

Emil Dotchevski wrote:
> On Thu, Nov 19, 2009 at 5:24 AM, Stewart, Robert
> <Robert.Stewart_at_[hidden]> wrote:
> > Emil Dotchevski wrote:
> >>
> >> 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.

_____
Rob Stewart                           robert.stewart_at_[hidden]
Software Engineer, Core Software      using std::disclaimer;
Susquehanna International Group, LLP  http://www.sig.com

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.