Boost logo

Boost :

Subject: Re: [boost] Official warnings policy?
From: Zachary Turner (divisortheory_at_[hidden])
Date: 2009-11-04 13:56:42


On Wed, Nov 4, 2009 at 12:29 PM, Emil Dotchevski
<emildotchevski_at_[hidden]>wrote:

> On Wed, Nov 4, 2009 at 10:03 AM, Mateusz Loskot <mateusz_at_[hidden]>
> wrote:
> > John Maddock wrote:
> >>
> >> I'm *not* saying we should do this for 1.41, but should we have an
> >> official policy regarding compiler warnings and which ones we regard
> >> as "failures"?
> >>
> >> I realize these can get pretty busy-body at times, but if the user
> >> sees several pages of warnings when building Boost it doesn't look so
> >> good. So my suggestion would be that we have two test-runners (if we
> >> have any spare!) that build with warnings-as-errors, maybe:
> >>
> >> -Wall -pedantic -Wstrict-aliasing -fstrict-aliasing -Werror
> >
> > By the way, building Boost gives large number of warnings related to
> > strict aliasing.
>
> As long as these warnings report actual violation of the C++ standard
> (as opposed to warning about a potential for violation) they should be
> fixed IMO.

I'm not sure I agree. If something is a violation of the C++ standard the
compiler shouldn't be reporting it as an error in the first place. For
example, implicit conversion between numeric types losing precision is going
to issue a warning on MSVC (not sure about GCC) but there's no violation of
the standard anywhere. Perhaps this is what you meant and I'm just taking
what you said too literally.

That aside, should we consider how to deal with #pragma warning(disable) in
MSVC (do other compilers have similar pragmas)? Should it be disallowed?
 Otherwise it's all too easy for a library maintainer who doesn't want to
fix a certain warning to just stick a pragma in there to disable it.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk