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

Subject: Re: [boost] [new Warnings policy] MS C4180 on theMaintenance Guidelines
From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2009-11-20 11:58:23

> -----Original Message-----
> From: boost-bounces_at_[hidden] [mailto:boost-bounces_at_[hidden]] On
Behalf Of
> John Maddock
> Sent: Friday, November 20, 2009 4:17 PM
> To: boost_at_[hidden]
> Subject: Re: [boost] [new Warnings policy] MS C4180 on theMaintenance
Guidelines
> >
> > 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.

So well put that I have added the essence of these to the

https://svn.boost.org/trac/boost/wiki/Guidelines/MaintenanceGuidelines

Paul

---
Paul A. Bristow
Prizet Farmhouse
Kendal, UK   LA8 8AB
[phone], mobile [phone]
pbristow_at_[hidden]