Re: [boost] Current Guidance on Compiler Warnings?

Subject: Re: [boost] Current Guidance on Compiler Warnings?
From: Gavin Lambert (boost_at_[hidden])
Date: 2018-11-22 03:43:40

On 22/11/2018 14:49, Emil Dotchevski wrote:
> First, any change in a correct program can introduce a new bug. Secondly,
> "fixing" a warning often alters the semantics of the operation in a subtle
> way. Consider for example the use of an explicit cast to silence a warning
> that an implicit conversion may lead to something bad. You may think that
> all you've done is silence the warning, but in fact you've changed the
> program semantically: it no longer does an implicit type conversion,
> instead it does an explicit one. And the thing is, one of the two is
> incorrect.
> 
> Now, if your programmers don't understand how implicit type conversions
> work in C++, it is possible that enforcing warning-free compilation avoids
> more bugs than it causes. If that's the case, there's no argument.

Perhaps I am one of these programmers who don't understand how implicit 
type conversions work (although I don't believe so), but...

Where implicit conversions are permitted, there is no difference in 
actual compiled behaviour at the call site between an implicit and 
explicit conversion.  At all.  They are utterly identical.

There *is* a difference in the warnings, because the compiler will emit 
warnings "hey, this can do unintended things sometimes, did you really 
want to do that?" for the implicit case and not for the explicit case, 
because for the latter it assumes you know what you're doing.

There *is* also a difference at the target site (the class implementing 
the conversion) and its choice of whether it should allow or prevent 
implicit conversions (and as is typical of C++'s defaults being wrong 
most of the time, it is usually wrong to allow implicit conversions -- 
though not always).

(And getting that wrong can cause unintended implicit conversions, but 
those usually present themselves differently from the warnings we're 
talking about here.)

What is also true is that it is a bad idea to get into the habit of 
seeing such a warning and "I know, I'll fix it with an explicit cast" 
without looking closely at the code -- because *in some cases* this ends 
up concealing a genuine bug in the code which the compiler was trying to 
helpfully warn you about (such as potential for integer overflow or 
narrowing).

Ensuring that code compiles without warnings is very helpful, to make it 
easier to spot when new warnings crop up and need to be examined.  *But* 
you do have to be disciplined and analyse and test (preferably with 
input fuzzing) the code where the warnings appear, not just blindly (and 
sometimes incorrectly) putting in a cast to make the compiler shut up.

The compiler doesn't just issue warnings on any implicit conversions, 
only on those that seem potentially unsafe.  So you should not be 
ignoring these, you should be fixing them.  Sometimes that means making 
an explicit conversion instead.  Sometimes that means changing types or 
verifying input sanity.  Sometimes something else.  But it shouldn't be 
left producing warnings when it can be (properly) fixed.