Mail Archives: djgpp/2000/07/03/14:20:41
> 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.)
- Raw text -