C++ Logo


Advanced search

Re: Out-of-range floating-point conversion behavior

From: Myria <myriachan_at_[hidden]>
Date: Thu, 6 Jun 2019 17:57:28 -0700
On Tue, Jun 4, 2019 at 22:34 Thiago Macieira via Std-Discussion <
std-discussion_at_[hidden]> wrote:

> On Tuesday, 4 June 2019 12:59:33 PDT Myria via Std-Discussion wrote:
> > But "the source value is between two adjacent destination values" is
> > true; namely FLT_MAX and +infinity. With this interpretation of the
> > wording, it seems like the result ought to be an
> > implementation-defined choice between FLT_MAX and +infinity. (I would
> > argue that because std::numeric_limits<float>::is_iec559() is true in
> > this implementation, its "choice" must be what IEC 559 / IEEE 754
> > mandates in this situation.)
> >
> > What is the correct interpretation here?
> I don't read that as the correct interpretation. Infinite is not adjacent
> to
> anything. Adjacency can only be seen between two finite numbers.
> In particular, I read the wording specifically for this case: out of
> range. If
> the number is bigger than the largest representable *finite* value or the
> smallest one, then it's UB.

Should I file an editorial issue to clear it up, then?

Also, I should look up IEEE 754 rules. C++ says floating-point divide by
zero is undefined behavior, but IEEE 754 defines it. Do implementations
that claim support IEEE 754 in is_iec559 have to define floating-point
operations that IEEE 754 defines but C++ itself does not?


Received on 2019-06-06 19:59:26