This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Simplify HUGE_VAL definitions [committed]
- From: Zack Weinberg <zackw at panix dot com>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Fri, 1 Sep 2017 07:41:54 -0400
- Subject: Re: Simplify HUGE_VAL definitions [committed]
- Authentication-results: sourceware.org; auth=none
- References: <alpine.DEB.2.20.1708311551080.24662@digraph.polyomino.org.uk> <CAKCAbMhj_gmveaW6G-sj=vPzr30N3m_+hb-0TtFYzd9v4bCptw@mail.gmail.com> <alpine.DEB.2.20.1708311651540.24662@digraph.polyomino.org.uk>
On 08/31/2017 12:53 PM, Joseph Myers wrote:
> On Thu, 31 Aug 2017, Zack Weinberg wrote:
>>
>> Otherwise use a numeric constant larger than the largest
>> representable finite value in any supported floating-point
>> format; in the normal rounding mode, ISO C requires this to be
>> rounded to +Infinity, if it exists, or else to the largest
>> representable positive value.
Hang on, is this actually true? N1570 §6.4.4.2p3 says
# ... For decimal floating constants, and also for hexadecimal
# floating constants when FLT_RADIX is not a power of 2, the result is
# either the nearest representable value, or the larger or smaller
# representable value immediately adjacent to the nearest
# representable value, chosen in an implementation-defined manner.
which would appear to license 1e10000 to be converted to either +Inf
or DBL_MAX regardless of rounding mode.
(Same wording in C99.)
zw