-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
According to Gary V. Vaughan on 2/23/2009 7:39 PM:
> hppa2.0-hp-hpux10.20-hpc1037 m4 fails: 175.format
> Checking ./175.format
> @ ../doc/m4.texinfo:5978: Origin of test
> ./175.format: stdout mismatch
> *** m4-tmp.11726/m4-xout Mon Feb 23 21:34:51 2009
> --- m4-tmp.11726/m4-out Mon Feb 23 21:34:51 2009
> ***************
> *** 3,8 ****
> 1
> 56790
> 5000
> ! success
> success
> 20
> --- 3,8 ----
> 1
> 56790
> 5000
> ! 17976931348623157100000...
Ouch - it looks like this platform parsed "inf" as a huge value, then
printed it as a finite value rather than infinity. I can't tell whether
the strtod misparsed inf, or whether it gave a valid infinite value which
was then mishandled by isinf(). Can you run 'make -k check' to see if it
at least passes gnulib tests? Can you run any further debugging on your
side, to see if you can spot where 'format(%010F,infinity)' starts
treating the value as a finite?
Hmm, a closer look at POSIX makes it appear that on non-IEEE machines, it
is feasible to not support infinity, in which case strtod("inf",NULL) must
fail with ERANGE and a value of HUGE_VAL. Does the hardware even support
IEEE infinities? If not, I need to correct the strtod tests to cater to
hardware that lacks infinity.
- --
Don't work too hard, make some time for fun as well!
Eric Blake [email protected]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkmj90AACgkQ84KuGfSFAYAfYwCdEF+BkZnjC+/+2WSCxpq/T7ej
rrUAn0NrZ7sNhV//KDOpTpi6h6P687Tn
=3ruZ
-----END PGP SIGNATURE-----
