This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Simplify HUGE_VAL definitions [committed]
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Zack Weinberg <zackw at panix dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Fri, 1 Sep 2017 12:04:18 +0000
- 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> <0a429628-dfbc-9eaf-4e19-26d9cfa22bde@panix.com>
On Fri, 1 Sep 2017, Zack Weinberg wrote:
> 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.
Annex F requires conversions of constants (with at most DECIMAL_DIG
digits) to be to-nearest. (TS 18661-1 adds the FENV_ROUND pragma to
choose a different rounding mode for them and for certain operations.)
--
Joseph S. Myers
joseph@codesourcery.com