Date: Tue, 26 Oct 1999 08:26:01 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Waldemar Schultz <schultz AT ma DOT tum DOT de>
cc: djgpp AT delorie DOT com
Subject: Re: exception handling.
In-Reply-To: <38147AB0.32EB329@ma.tum.de>
Message-ID: <Pine.SUN.3.91.991026082541.17216E-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Note-from-DJ: This may be spam
Reply-To: djgpp AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk


On Mon, 25 Oct 1999, Waldemar Schultz wrote:

> 0
> NaN
> NaN
> CtrlBreak 295
> 
> But I'd have epected something like:
> 
> 0
> errno xxx
> NaN
> errno xxx
> NaN
> CtrlBreak 295
> 
> Any explanation please ??

It's all in the docs: see the docs of the library function `_control87'.
There you will see that DJGPP startup code by default masks all
numeric exceptions, so all the invalid FP operations your code
attempts to do don't raise SIGFPE at all, and your handler isn't
called.  Use `_control87' to unmask some of the exceptions, and the
program will work as you expect.

Your program is also based on another assumption: that math functions
in libc.a set errno when you attempt an invalid operation.  This is
not true in v2.02; link with -lm if you want errno to be set (see
"info libc alpha libm" and "info libc alpha matherr" for more info
about this).

Note that, if you unmask numeric exceptions, SIGFPE is raised *before*
the called math function gets to look at the result (a NaN or an Inf)
produced by the invalid operation.  This means that you cannot have
both SIGFPE and errno.  I suggest to leave the numeric exceptions
masked, link with -lm, and write your own matherr function to serve
instead of the SIGFPE handler.