Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 6 Nov 1995 20:47:43 +1100
From:      Bruce Evans <bde@zeta.org.au>
To:        bde@zeta.org.au, markd@grizzly.com
Cc:        freebsd-hackers@freebsd.org, jkh@time.cdrom.com, julian@ref.tfs.com
Subject:   Re: NPX still broken in 2.1.0-951104-SNAP...
Message-ID:  <199511060947.UAA10166@godzilla.zeta.org.au>

next in thread | raw e-mail | index | archive | help
>>I think the current behaviour (trapping) is more useful for
>>most programs.  Programs that can handle IEEE arithmetic
>>should do something special to check and get it at confiuration
>>time since it is not guaranteed.

>Its incompatible with every Unix system I have access to.  See enclosed table.
>No system core dumps!  I don't have any standards handy, but SCO, which
>is X/Open, ANSI, and POSIX compatible sets errno and returns NaN.

The ANSI standard says that math functions shall not cause any externally
visible exceptions; for domain errors, errno shall be set to EDOM and an
implementation-defined value shall be returned; for range errors, errno
shall be set to ERANGE and a correctly signed +-HUGE_VAL shall be returned.

What do these systems do for common application errors?  E.g.,

/* 1. Overrun i387 stack. */
main() { int i; for (i = 0; i < 1000; ++i) foo(); } double foo() { return 0; }

/* 2. Overflow. */
#include <math.h>
main() { double volatile d; d = pow(1e6, 1e6); d += d; d += d; }

/* 3. Invalid operation. */
#include <math.h>
main() { double volatile d; d = pow(1e6, 1e6); d -= d; d -= d; }

(I assume that HUGE_VAL is +Infinity...)

Systems that use __IBCS_NPXCW__ for the default control word have to do
extra work in the library functions so that the library functions don't
trap.  I think some of the i386 Unixes do this.

>>The change similar to mapping page 0 and putting 0's there so
>>that strcmp("foo", NULL) works right.  
>>Surely such a simple change that might help some people
>>is worth puting in now? ;-)

>I don't see this as being analogous. strcmp to NULL is an undefined, invalid
>operation.  IMHO calling acos with an out of range operand is an error case
>akin to calling open with an invalid file name.  The big difference between
>this and strcmp is that you can read a man page and find out the expected
>error respones.

The problem is that the control word is global so changing it affects the
behaviour of d += d and d-= d above as well as fixing the library functions.

>It seems pretty straight forward to modify k_standard.c to return NaN
>in POSIX_MODE.  Making the modified POSIX mode the default, and changing the

The correct value isn't passed to __kernel_standard() so one has to be
invented.  This is fairly easy for acos(|x|>1) because there is only
one reasonable value (the default NaN).  Other cases are more difficult.
E.g., for pow(0, negative), the correct value is +HUGE_VAL for +0 and
-HUGE_VAL for -0 but __kernel_standard always returns -HUGE_VAL.  There
are 19 different cases for the `IEEE' version of pow(), but only 6 cases
for pow() in __kernel_standard().

>----------------------------------------------
>SCO 3.2v5:
>acos (2.0) = nan, errno = 33

Correct.

>----------------------------------------------
>BSDI 1.1:
>acos (2.0) = NaN, errno = 0

Wrong errno (from BSD libm?).

>----------------------------------------------
>HP-UX A.09.01:
>acos: DOMAIN error
>acos (2.0) = 0, errno = 33

Bogus side effect (extra output).

>----------------------------------------------
>IRIX 5.3
>acos (2.0) = nan0x7fffffff, errno = 33
>----------------------------------------------
>OSF/1 V3.0
>acos (2.0) = 0, errno = 33
>----------------------------------------------
>ULTRIX 4.3 
>acos (2.0) = NaN, errno = 33

Correct.

>----------------------------------------------
>SunOS olden 4.1.3_U1 1 sun4c
>acos: DOMAIN error
>acos (2.0) = NaN, errno = 33
>----------------------------------------------

Bogus side effect.

Bruce



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199511060947.UAA10166>