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
> John Maddock
> Sent: Friday, November 20, 2009 4:17 PM
> To: boost_at_[hidden]
> Subject: Re: [boost] [new Warnings policy] MS C4180 on theMaintenance
> > 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
--- Paul A. Bristow Prizet Farmhouse Kendal, UK LA8 8AB +44 1539 561830, mobile +44 7714330204 pbristow_at_[hidden]
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk