This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Simplify HUGE_VAL definitions [committed]


On Fri, Sep 1, 2017 at 8:04 AM, Joseph Myers <joseph@codesourcery.com> wrote:
> 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.)

Yes, but for any constant greater than <type>_MAX, <type>_MAX is
arguably nearer to that constant than +Infinity is.

zw


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]