Re: [boost] Current Guidance on Compiler Warnings?

Subject: Re: [boost] Current Guidance on Compiler Warnings?
From: Vinnie Falco (vinnie.falco_at_[hidden])
Date: 2018-11-22 21:05:16

Apologies for the top post as I am on a tablet and can’t be arsed with
wrestling the iOS text selection interface. As the author of Beast I strive
to eliminate all warnings no matter how small. Otherwise users will
complain and I will still end up having to fix them anyway.

That said, there were a number of odd compiler version-specific warnings
which have plagued me for over a year. I am pleased to credit Damian Jarek
for getting to the bottom of the worst one, which manifests in gcc 8 and
later as a “possibly uninitialized” variable warning. For months we thought
it was spurious, but he got to the bottom of it and figured it out.

In terms of user satisfaction, it enhances the reputation of a library when
it can be consistently used without producing warnings. Or rather, it
tarnished the reputation of the library when warnings appear. “Fixing all
the warnings” is usually a cheap but effective way to raise the prestige of
a library.

Thanks

On Mon, Nov 19, 2018 at 11:21 AM Brian Kuhl via Boost <boost_at_[hidden]>
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.
>
> Many thanks
>
> Brian Kuhl
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>
-- 
Follow me on GitHub: https://github.com/vinniefalco