Re: Boost warning philosophy

From: Peter Dimov (pdimov_at_[hidden])
Date: 2022-08-30 07:05:27

Scott Johnson wrote:
> Hello,
> 
> We are migrating a legacy codebase (embedded system though a PC
> architecture) from Centos 7.x, using various boost 1.5x components and GCC
> 7.3, to Ubuntu 22.04 and GCC 11.2 (the compiler that ships with this version
> of Ubuntu).  As our application needs things that don't come with the "stock"
> Boost version that Canonical packages for 22.04, specifically Python 2.x
> support, I have downloaded and configured Boost 1.80 for our application to
> use.
> 
> Unfortunately, our code development standard is -Wall -Werror (turn on all
> warnings and treat them as errors), with exceptions to -Wall only allowed
> grudgingly.  And this version of Boost seems to break things, with all sorts of
> warnings being thrown that we simply don't see on the older version, distro,
> and toolchain.  One of the biggest offenders seems to be things like #if
> _MSC_VER when this preprocessor symbol is not defined--GCC likes to warn
> that the symbol is being "defaulted" to zero in this context.  (Defining it as 0
> causes all heck to break loose, as there is also plenty of #ifdef _MSC_VER in
> the code).  I've also seen warnings for overloaded virtual functions being
> hidden (a warning I would prefer not to disable), null pointer dereferences
> (ditto), and local variables being shadowed (ditto) from various Boost
> components.
> 
> This is on production builds with -O2 optimization level.
> 
> What is, if anything, the Boost policy towards compiler diagnostics of this sort?

There is no overarching Boost policy on warnings; you need to submit issues
against the offending libraries.

For #if _MSC_VER, that's almost always something that needs to be fixed, but
at the same time, I don't think this warning (-Wundef) is on by default, so it's
usually not being tested. Ditto for -Wshadow - also off by default (not in -Wall).

Also, it's not always the case that a newer compiler would emit more warnings.
Newer compilers introduce new warnings, but sometimes tone down
previous ones.

Maybe you can post some specific examples that we can discuss.