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
       necessarily representable as a float.
       ...
       HUGE_VAL,   HUGE_VALF,  and  HUGE_VALL  can  be  positive
       infinities in 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 INFINITY
	return 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

Sun, 14 Mar 2004 16:44:43 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Remaining platform dependencies in float stuff