-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of John Maddock Sent: Friday, November 20, 2009 4:17 PM To: boost@lists.boost.org 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 +44 1539 561830, mobile +44 7714330204 pbristow@hetp.u-net.com