test_9 (0.0/0.0, "+nan.0") fails on OpenBSD and FreeBSD

test_9 (0.0/0.0, "+nan.0") fails on OpenBSD and FreeBSD

[Andreas Vögele]

The test test_9 (0.0/0.0, "+nan.0") in 
test-suite/standalone/test-conversion.c fails on OpenBSD and FreeBSD. 
The problem is that NaN may be negative or positive on these systems. 
The function real_eqv in libguile/eq.c, which uses memcmp to compares 
doubles, doesn't take this into account.

Here's output from gdb that shows the problem. The negative value -NaN 
of "x" is the value of "guile_NaN", which is calculated with the 
expression "guile_NaN = guile_Inf / guile_Inf" in numbers.c on BSD.  
The positive value NaN of "y" is the result of 0.0/0.0.

test_9 (val=NaN(0x8000000000000), result=0x3c00089e "+nan.0") at 
test-conversion.c:785
Breakpoint 3, real_eqv (x=-NaN(0x8000000000000), 
y=NaN(0x8000000000000)) at eq.c:61

Here's a version of real_eqv that works correctly on BSD:

static int
real_eqv (double x, double y)
{
  return !memcmp (&x, &y, sizeof(double)) || (x != x && y != y);
}

Since NaN != NaN, the expression "(x != x && y != y)" is true if "x" 
and "y" are both NaNs.



_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile

Re: test_9 (0.0/0.0, "+nan.0") fails on OpenBSD and FreeBSD

[Marius Vollmer]

Andreas Vögele <voegelas@gmx.net> writes:

> The problem is that NaN may be negative or positive on these
> systems. The function real_eqv in libguile/eq.c, which uses memcmp
> to compares doubles, doesn't take this into account.

Hmm.  Another stance on this is that real_eqv does in fact take this
into account and correctly distinguishes between different NaNs.
Guile pretends that there is only one NaN, but that isn't true.

There are all kinds of IEEE NaNs and why should 'eqv?' pretend they
are all the same?

The bug would be in the test case then.  It should use 'nan?' to check
for NaNs.

But we then also need to print different NaNs differently and be able
to read them...


But the simplest thing is to apply your patch.  I have done so.

PS: the problem also appears on GNU/Linux with GCC 3.4.


_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile