Re: [boost] Current Guidance on Compiler Warnings?

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
> https://svn.boost.org/trac10/wiki/Guidelines/WarningsGuidelines
> 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