Message-Id: <200007031820.VAA11428@mailgw1.netvision.net.il>
Date: Mon, 03 Jul 2000 21:20:51 +0200
To: Waldemar Schultz <schultz AT ma DOT tum DOT de>
X-Mailer: Emacs 20.6 (via feedmail 8.2.emacs20_6 I) and Blat ver 1.8.5b
From: "Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
CC: djgpp AT delorie DOT com
In-reply-to: <39608EF6.FC0856D1@ma.tum.de> (message from Waldemar Schultz on
	Mon, 03 Jul 2000 15:02:46 +0200)
Subject: Re: Floating point exception
References:  <39608EF6 DOT FC0856D1 AT ma DOT tum DOT de>
Reply-To: djgpp AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> From: Waldemar Schultz <schultz AT ma DOT tum DOT de>
> Newsgroups: comp.os.msdos.djgpp
> Date: Mon, 03 Jul 2000 15:02:46 +0200
> 
> I am messing around with huge nmumerical programs and I need to implement FPE
> on any abnormal FP operation.

Isn't it better to link against libm.a and write a custom version of
`matherr'?  See "info libc alpha matherr" for more information.

> The second problem is: is it possible to throw an exception when a number
> becomes NaN (NOTaNUMBER) ir Inf (Infinite) ?

You will have to give more details about how exactly do these come
into existence.  Does it happen in an FP instruction such as division
or multiplication?  Does it happen in a function?  The answer depends
on these details.

> static void FloatError(int sig)
> {
> unsigned int sw;
> 
>  sig=sig; //shutup
>  sw=_status87();

This is redundant: _clear87 returns the previous status word.  You
should generally call _clear87 and _fpreset as soon as possible after
you enter the SIGFPE handler.

>   signal(SIGFPE,Fpe);   // floating point

This is redundant with DJGPP (the signal handler is not reverted when
a signal is raised).

>  y=log(b); printf("%Lg\n",y); //-Inf no FPE :-(
>  a=a/b;                       //FPE signalled

This is expected behavior: both libm.a and libc.a (as of v2.03)
examine the arguments of math functions *before* computing the
function's value, and if the argument is about to produce an abnormal
result, Inf or NaN are manually copied to the return value.  So SIGFPE
never happens.

If you use `matherr', you will be able to work around this difficulty.
`matherr' gives you a much finer degree of control on what happens
when a math function is called with bad arguments.  You get to see
what arguments were passed to the function, how will the function
react, what result it will return, and can even correct the arguments
on the fly, if you want.

In addition, I think that avoiding FP exceptions is a Good Thing, for
the following reasons:

  - FP exceptions, at least as they are handled in DJGPP, are
    notoriously fragile.  On Windows/NT, if you try to catch SIGFPE,
    your program crashes.  On Windows 9X, if the FP exception happens
    inside nested DJGPP programs, SIGFPE gets delivered to the
    parent(!).  Debugging a program that triggers FP exceptions is
    hard and might not work.  Etc., etc.

  - ANSI C in its C89 incarnation required programs not to crash when
    abnormal math results are generated, but instead set errno to an
    appropriate value; this is not possible if SIGFPE is raised.
    (Ironically, the new C standard reversed this, and it now
    *requires* programs to generate an exception, and setting errno is
    not required.  This is something that future DJGPP development
    will have to deal with.)