Subject: Re: [boost] Current Guidance on Compiler Warnings?
From: Brian Kuhl (kuhlenough_at_[hidden])
Date: 2018-11-21 04:20:40
I agree with you, I understand the desire of the industry to institute
demonstrable measures of quality in the face of mounting costs associated
with certifying code. Or should I say, the increasing size and complexity
of code that they want to certify. But the result is often a cast that is
placed without good understanding of the context. I'd love to see more
emphasis tools like coverity, klockwork, that look for less obvious issues,
and languages like Rust that avoid common issues with more rigorous
syntax. At least with boost.org we have the benefit of some very good
maintainers to act as gatekeepers and avoid the worst of these uninformed
On Mon, 19 Nov 2018 at 15:03, Emil Dotchevski via Boost <
> On Mon, Nov 19, 2018 at 11:21 AM Brian Kuhl via Boost <
> > 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
> > 7 (with Dinkum 7.00 with and Clang 6.0 for ARM and IA boards and GCC
> > 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
> > to be pedantic about eliminating all compiler warnings.
> In that context there are probably legal reason for zero-warning policy,
> but it is not true that lack of warnings means fewer errors, in fact it
> could easily lead to more errors. For example warnings about implicit
> conversions are frequently "fixed" by replacing the implicit conversion
> with explicit conversion (cast). But the two are semantically very
> different, and therefore one of them is incorrect, and very likely that is
> the explicit one.
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk