[net.unix] catching FPEs?

colin@vu-vlsi.UUCP (Colin Kelley) (10/01/86)

I'm using 4.2bsd on a Pyramid.  I'm working on a plotting program which
allows users to plot arbitrary functions.  Sometimes these functions will
blow up for one reason or another (usually because their argument is out
of range), giving a Floating Point Exception, followed by a core dump.  I
already trap obvious things like division by zero in my own code, setting a
flag to mark the current data point as undefined (so it is not plotted).  Now
I want to trap FPEs using signal(), having my FPE handler routine set the same
flag, then continue.  Unfortunately, it seems that when my handler routine
returns, the same FPE is occurring again, causing an infinite loop...

Is there some way to trap FPEs and then indicate that you want to resume
execution _after_ the code which caused the FPE?  (setjmp()/longjmp() won't
work too well here because I don't just want to return to one place--I want
to continue execution wherever it left off.)  Or is there a way to modify the
argument which was passed into that code so that it will be able to continue
without another FPE?

Thanks...

			-Colin Kelley ..{cbmvax,pyrnj,psuvax1}!vu-vlsi!colin

perry@vu-vlsi.UUCP (Rick Perry) (10/02/86)

In article <371@vu-vlsi.UUCP> colin@vu-vlsi.UUCP (Colin Kelley) writes:
>I'm using 4.2bsd on a Pyramid...
>...
>Is there some way to trap FPEs and then indicate that you want to resume
>execution _after_ the code which caused the FPE?

You didn't mention that your program is written in C, but I guess that's
the default in the Real World.  If it was Fartran, you could simply do:

	call trpfpe( inmax(), dflmax() )

thereby specifying that Floating Point Execptions are to be replaced
by dflmax() (largest double float on the machine) for up to inmax()
(largest integer on the machine) occurances.  These things are available
on Pyramid from f77, don't know about other machines, but perhaps there
is an easy way to call that from C on Pyramid ? 

When you do that, the FPE's are trapped and fixed, and msg like:

on_fpe: floating point exception (or overflow or something...)

or something like that is printed on stdout or stderr, not sure which...

...Rick			..somewhere!here!f77!vu-vlsi!perry

chris@umcp-cs.UUCP (Chris Torek) (10/04/86)

In article <371@vu-vlsi.UUCP> colin@vu-vlsi.UUCP (Colin Kelley) writes:
>... Is there some way to trap FPEs and then indicate that you want
>to resume execution _after_ the code which caused the FPE?

Yes, but this is extermely machine dependent.

If you peer closely at the 4.2 or 4.3 BSD signal manual entries,
you will find something called `sigcontext'.  This includes enough
of the call frame so that you can alter the return point, and the
stack pointer and/or frame pointers if necessary.  The way to do
this is no doubt quite different on a Pyramid than on a Vax.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1516)
UUCP:	seismo!umcp-cs!chris
CSNet:	chris@umcp-cs		ARPA:	chris@mimsy.umd.edu