Re: [lmi] Integer overflow warnings in bourn_cast with clang

[Vadim Zeitlin]

On Thu, 6 Apr 2017 20:23:51 +0000 Greg Chicares <address@hidden> wrote:

GC> Let me ask your opinion on another issue: conversion to bool.
GC>   static_cast<int>(DBL_MAX);  // undefined behavior [conv.fpint/1]
GC>   static_cast<bool>(DBL_MAX); // result is 'false' [conv.bool]
GC> At the moment, bourn_cast rejects both, and I'm inclined to keep it that
GC> way, but do you disagree?

 Quite on the contrary, I couldn't agree more.

GC> The reason I ask is that I'm trying to summarize what bourn_cast is
GC> supposed to do. One of its goals is to avoid all conversions that
GC> constitute undefined behavior (at least, as far as possible--I'm not
GC> sure we can guarantee that if floating point doesn't follow IEEE 754).
GC> Strict value preservation can't be a goal if we allow
GC>   bourn_cast<float>(ULL_MAX);
GC> yet we've decided to disallow silent truncation
GC>   bourn_cast<int>(2.71828);

 Conceptually bourn_cast<> is value-preserving, but what exactly is meant
by "value preservation" depends on the type being casted to and this
condition is relaxed it it is a floating point one.

GC> so I think the best description is...
GC> 
GC>   Do what static_cast does, when its behavior is defined, iff the
GC>   source value is within the target type's [lowest(), max()] range;
GC>   throw otherwise. However, throw if floating-to-integral conversion
GC>   would truncate, because that circumstance calls for rounding [this
GC>   is the only intentional difference from boost::numeric_cast].

 I think it's the same thing as I'm saying, but it seems preferable to me
to state that this cast is mostly strictly value preserving, except for the
specific case of casting to a less precise floating point type.

GC>   Corollary: integral-to-integral conversion either preserves value
GC>   or throws.

 But, in any case, this is the important part.

GC> Then the present behavior of bourn_cast<bool> follows immediately.
GC> I think that's reasonable because nobody writes static_cast<bool>
GC> anyway:

 Yes, I can't see any realistic use case for using bourn_cast<bool>. But I
guess it could happen in some generic code, perhaps?

GC> We want bourn_cast<bool> to be defined so that bourn_cast can convert
GC> between any arithmetic types, and so that value_cast can convert
GC> between any types for which it's defined. But we don't have to extend
GC> the domain to values other than T(true) and T(false) for a general
GC> arithmetic type T. Or am I missing something?

 No, I don't think so.
VZ