Even after Neil's recent round of fixes, I'm still seeing regression
failures in the float tests on HPUX. Some investigation reveals the
cause: the current float.c code assumes that HUGE_VAL is an IEEE
Infinity. On HPUX it is just the largest normal double value:
# define HUGE_VAL 1.7976931348623157e+308
which means we get bogus overflow errors for cases like 'Infinity'::float4.
AFAICS both approaches are valid: the C99 spec says
[#3] The macro HUGE_VAL expands to a positive double constant expression, not
necessarilyrepresentable as a float. ... HUGE_VAL, HUGE_VALF, and HUGE_VALL can be positive
infinitiesin an implementation that supports infinities.
Note it says "can be" not "must be", so even though HPUX does support
IEEE infinity, it's valid for HUGE_VAL not to be one.
We are likely to see related portability issues on other platforms
now that the regression tests are actually testing for infinity support.
The C99 spec requires implementations to define macros INFINITY and NAN
for those values if they are supported, but no such macros appear in the
HPUX 10.20 <math.h>, nor probably in a lot of other pre-C99 platforms.
What I propose to do about this is to centralize knowledge of how to
create an infinity or NAN into four small functions in float.c, for
example
double
get_float8_infinity(void)
{
#ifdef INFINITYreturn INFINITY;
#else/* an overflow should result in Infinity on most IEEE machines */return HUGE_VAL * HUGE_VAL;
#endif
}
and similarly for get_float8_nan(), get_float4_infinity(), get_float4_nan().
This will provide a single place in which to cope with platform-specific
spellings for these values. I am not totally certain that we need to
distinguish float and double versions of these functions, but better
safe than sorry.
Thoughts?
regards, tom lane