Re: build failure (alpha-current): floating point exception 8

[christos%zoulas.com@localhost (Christos Zoulas)]

On Mar 3,  3:13pm, njoly%pasteur.fr@localhost (Nicolas Joly) wrote:
-- Subject: Re: build failure (alpha-current): floating point exception 8

| On Tue, Mar 03, 2009 at 08:53:08AM -0500, Christos Zoulas wrote:
| > On Mar 3,  2:16pm, njoly%pasteur.fr@localhost (Nicolas Joly) wrote:
| > -- Subject: Re: build failure (alpha-current): floating point exception 8
| > 
| > | > njoly@thanos [~/tmp]> gdb /local/src/NetBSD/tool/bin/nbawk 
| > | > GNU gdb 6.5
| > | > [...]
| > | > This GDB was configured as "alpha--netbsd"...
| > | > (gdb) run '$NF!~/^rump/' 1.out
| > | > Starting program: /local/src/NetBSD/tool/bin/nbawk '$NF!~/^rump/' 1.out
| > | > [...]
| > | > Program received signal SIGFPE, Arithmetic exception.
| > | > 0x0000000120011004 in is_number (s=0x160308024 "nanotime")
| > | >     at /local/src/NetBSD/src/dist/nawk/lib.c:713
| > | > 713             if (ep == s || r == HUGE_VAL || errno == ERANGE)
| > | 
| > | To be sure, i removed the `r == HUGE_VAL' and the build succeeded.
| > | 
| > | If i understand correctly, HUGE_VAL is used to check for for infinity
| > | (wonder if INFINITY should be used instead ?). But nothing check for
| > | NaN ...
| > | 
| > | While here i noted that strtod(3) man page state that `NAN' sequence
| > | string are not supported, which does not looks correct anymore:
| > | 
| > |      -   one of NAN or NAN(n-char-sequence-opt), ignoring case. This
| > |          implementation currently does not interpret such a sequence.
| > 
| > I think one should use isinf() or isnan(), since there is +/- inf and many
| > nans.
| 
| Are they portable enough for host tool ? My Tru64 do miss isinf().

Ouch. These are IEEE Std 1003.1-2001 functions, and are extensions to the ISO C
standard. Strtod is supposed so return HUGE_VAL if the value is going to
overflow. HUGE_VAL in term is defined to be infinity in our implementation,
but is that guaranteed to be that way? I am not sure. Anyway, it seems that
inf == inf traps on non-ieee hardware, so we need to take care of it somehow.
perhaps using memcmp()? I really don't want to longjmp out of a signal handler
to solve this.

christos