This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Simplify HUGE_VAL definitions [committed]
On Fri, Sep 1, 2017 at 10:59 AM, Joseph Myers <joseph@codesourcery.com> wrote:
> On Fri, 1 Sep 2017, Zack Weinberg wrote:
>
>> One more problem, which I should have thought to check earlier: 1e10000L
>> isn't big enough if long double is 128 bits wide (which it actually
>> appears to be on this computer):
>
> 1e10000L is big enough. For both x86 extended and binary128, the largest
> finite value is just below 2^16384 (about 1.2e4932).
Oh, right, I forgot *_MAX_EXP are binary.
I'm checking this in instead, then.
zw
* math/math.h (HUGE_VAL): Improve commentary.
diff --git a/math/math.h b/math/math.h
index bbc1ab9bfa..547b36d10e 100644
--- a/math/math.h
+++ b/math/math.h
@@ -37,11 +37,16 @@ __BEGIN_DECLS
/* Gather machine dependent type support. */
#include <bits/floatn.h>
-/* Value returned on overflow. On all IEEE754 machines, this is
- +Infinity. */
+/* Value returned on overflow. With IEEE 754 floating point, this is
+ +Infinity, otherwise the largest representable positive value. */
#if __GNUC_PREREQ (3, 3)
# define HUGE_VAL (__builtin_huge_val ())
#else
+/* This may provoke compiler warnings, and may not be rounded to
+ +Infinity in all IEEE 754 rounding modes, but is the best that can
+ be done in ISO C while remaining a constant expression. 10,000 is
+ greater than the maximum (decimal) exponent for all supported
+ floating-point formats and widths. */
# define HUGE_VAL 1e10000
#endif
#ifdef __USE_ISOC99