Re: [boost] Official warnings policy?

Subject: Re: [boost] Official warnings policy?
From: Patrick Horgan (phorgan1_at_[hidden])
Date: 2009-11-10 00:48:28

   Emil Dotchevski wrote:

     ... elision by patrick...
This assumes that a policy that requires warnings to be "fixed" is
desirable or that it will lead to a better Boost (note that I'm not
arguing against disabling warnings in Boost headers.)
  

   It's a safe assumption.  Having been through this pain a number of times I
   know that it leads to consistently better code.  I've seen it many times.
   In fact yesterday, coincidently, (or not, it was because I was talking to
   him about this discussion), I was working through the code of someone I
   highly respect as a programmer with decades of experience who's sat on a
   couple of different language standard committees, and while getting rid of
   warnings in his code, I found some real bugs.  Had he been used to running
   at a high warning level, those bugs wouldn't have crept into his code.  This
   didn't surprise me a bit.  It always happens.  You start building with
   higher warning levels on any large body of code and you always find real
   bugs.  That's the point of it.  A couple of them were really obvious, once
   the messages pointed me to them, but of course you know how our eyes see
   what we expect.  A lot of the warnings were annoying and made me do silly
   things, like reverse a condition so that I could move a throw up and a
   return down.  Some of them were technically bugs, like comparisons between
   signed and unsigned but in the problem domain we knew that the bug would
   never be hit, but still bad code, and sometimes you get data outside the
   problem domain--surprise!  Eventually I got it down to multiple copies of a
   warning  out  of  boost/archive/binary_oarchive.hpp signed vs unsigned
   conversion just from including it.  Frustrating.  In the next day or two
   I'll   get  back  into  it  and  figure  that  out  (it's  a  line  in
   basic_binary_oarchive::save_override).  You might think that a waste of
   time, but it's not.  The point is that now the code can be built normally
   with a higher warning level, and now that I've gotten rid of most of the
   noise, except for boost noise, more bugs will be caught before they get out
   in the wild.
   It's obvious that you don't like it.  I know.  It's a pain in the ass.
   But--there are real and large benefits that will help you and those that
   come after with this code for as long as people are building it and building
   with it.  The potential payoff is huge!   Just silencing all the warnings by
   disabling them means that you don't get the advantage that building with
   higher warning levels brings you.  Certainly, if that's all you were going
   to do, it would pointless.
   If you're sure a complaint is a bug for the compiler that generates the
   warning, write a bug against them, but silence it for your users.  Make sure
   if you do that that you revisit silencing it after the compiler writers fix
   their bug.
   Patrick