Boost logo

Boost :

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

On 28/11/2018 10:01, Emil Dotchevski wrote:
> Same is true about signed/unsigned implicit conversions. Do you want a
> warning in this case?

Yes. They are not compatible types, and so conversion should be treated
with suspicion by default.

As should hopefully be obvious, implicit narrowing conversions are never
a good idea.

Everyone recognises that conversion from intN_t to uintM_t or from
uintN_t to intM_t where N > M is a narrowing conversion, and this should
have a warning. This is not controversial.

Similarly everyone's happy that conversion from uintN_t to intM_t where
N < M is *not* a narrowing conversion and this can be done implicitly,
with no warning.

What is less obvious and more controversial but is still true:
conversion from intN_t to uintM_t or uintN_t to intM_t where N = M is
*also* a narrowing conversion (both ways), because there are values in
one that are not expressible in the other. This is *slightly* better
than the first case because the conversion is at least perfectly
reversible -- there is no loss or problem if you convert, store, and
then convert back before use -- as long as you never try to use the
value in the "wrong" type, or you have sufficient assurance that the
actual value falls within the common range of both types. (An assert
helps, but only if it happens to be hit with the bad input in a debug
build where someone reports the failure. Which will not catch all cases.)

And similarly intN_t to uintM_t where N < M is still always a narrowing
conversion, for the entire range of negative values. The conversion is
"safe" only if you have assurance that you don't have a negative value.

(Or if you do have a negative value and you're trying to do
bit-twiddling for performance reasons with an appropriate algorithm,
which generally assumes 2's complement representation and thus relies on
implementation-defined behaviour. Much safety is sacrificed on the
altar of performance. But even there it can and should be explicit
about the casting, since that doesn't impact performance.)

> I know, but it is still a valid question to ask what is the role of the
> cast. Does it make the program more readable? In what way is your version
> preferable?

It's an assurance (at least in theory) that someone is changing the type
intentionally rather than unintentionally.

It's the exact same reason that people are encouraged to make conversion
constructors and operators explicit, especially for potentially
narrowing conversions.

> You keep saying the original code is unsafe. How is the implicit conversion
> less safe than the cast?

See above. One shows intent, the other does not.

Boost list run by bdawes at, gregod at, cpdaniel at, john at