Boost logo

Boost :

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.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk