On Wed, Nov 4, 2009 at 12:29 PM, Emil Dotchevski <emildotchevski@gmail.com>wrote:
On Wed, Nov 4, 2009 at 10:03 AM, Mateusz Loskot <mateusz@loskot.net> 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.