Re: [boost] Current Guidance on Compiler Warnings?

Subject: Re: [boost] Current Guidance on Compiler Warnings?
From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2018-11-22 09:50:57

> -----Original Message-----
> From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of Robert Ramey via Boost
> Sent: 22 November 2018 01:11
> To: boost_at_[hidden]
> Cc: Robert Ramey
> Subject: Re: [boost] Current Guidance on Compiler Warnings?
> 
> On 11/19/18 11:20 AM, 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.
> >
> 
>  From my perspective, this would be OK.  OK - one changes some perfectly
> fine code to address a warning so we have easily verifiable "clean"
> code. It's just a little BS to keep everyone happy and it does help find
> some errors.  When one makes code for multiple compilers - it's a whole
> 'nuther ball game.  to make one's code pass warning free in such an
> environment ends up cluttering the code with lots of ... clutter.
> Remember we've got libraries support dozens of compilers - counting
> previous versions.  In this environment, it's a fools errand.

+1

We have multiple compilers, none of them really, really compliant with an imperfectly-specified language, producing different
warnings.

Trying to please every compiler and configuration all the time proves to be playing Whack-a-mole!

But at Boost, we try hard.

One of the objectives of gathering the WarningsGuidelines (https://svn.boost.org/trac10/wiki/Guidelines/WarningsGuidelines  - update
suggestions welcome, or you can edit it yourself) 

was to emphasize how supressing a warning *documents*  that the code has been examined and that the programmer has concluded that
the warning is not applicable here.

We can and should do better about documenting this as comments in the code.

Paul

---
Paul A. Bristow
Prizet Farmhouse
Kendal UK LA8 8AB
[phone]