Subject: Re: [boost] Current Guidance on Compiler Warnings?
From: Edward Diener (eldiener_at_[hidden])
Date: 2018-11-19 21:01:45
On 11/19/2018 2:20 PM, Brian Kuhl via Boost wrote:
> I'd like to confirm the guidance on Warnings I find here
> is still considered current?
> context ...
> At Wind River we are in the process of working with Boost 1.68 and VxWorks
> 7 (with Dinkum 7.00 with and Clang 6.0 for ARM and IA boards and GCC 8.1
> for PowerPC ) with the hope of bundling Boost with our product.
> Many of our customers make certified systems ( Planes, Trains, Medical
> Equipment, Factory Automation, etc. ) and the trend in theses industries is
> to be pedantic about eliminating all compiler warnings.
> While we have not traditionally required zero warnings in open source code
> shipped with our product, there is pressure on us to move in that
> direction, and as result we will probably be contributing pull requests
> specifically to fix or suppress compiler warnings over the coming years.
> I'd like to establish clear guidelines for my team as to what is an
> appropriate "coding standard" for Boost in regards to compiler warnings.
> While it is simple to say, everything displayed by -Wall, in practice there
> are many edge cases, e.g. is an unused parameter acceptable in test code?
> So I'd like to get the maintainers guidance.
Warning free is a nice ideal, but the truth is more complicated. Many
warnings are not really about possible coding mishaps but about a sort
of lint-like standard which compilers now want to enforce and have
nothing to do with correct C++ code. Other warnings are simply
erroneous, as is prevalent most everywhere in the current default VC++
preprocessor. Eliminate even the first class of warnings is often a
fool's errand AFAIAC. All one ends up doing is adding completely
unnecessary code restrictions to what is perfectly acceptable C++ code.
A typical example is some variable whose name hides a variable in an
outer scope. This is perfectly acceptable C++ code but now many
compilers issue a warning when this happens. I object to having to worry
about coming up with a unique name to all variables in whatever scope in
some translation unit just to avoid such a warning. This process of
warnings enforcing coding standards goes on and on and I do not think it
is possible, or advisable timewise, to spend unnecessary time pleasing
every compiler's notion of what these lint-like warnings entail. I am
not against spending time eliminating warnings when the warning itself
points top some loose use of C++. But I am against spending time on
eliminating warnings when the warning is just some lint-like alarm over
what might be an error but is perfectly normal and acceptable C++ code.
> Many thanks
> Brian Kuhl