Xref: utzoo comp.os.msdos.programmer:2956 alt.msdos.programmer:2372
Path: utzoo!utgpu!cs.utexas.edu!sun-barr!apple!netcom!resnicks
From: resnicks@netcom.UUCP (Steve Resnick)
Newsgroups: comp.os.msdos.programmer,alt.msdos.programmer
Subject: Re: Trapping Floating Point Errors in Turbo C
Message-ID: <21906@netcom.UUCP>
Date: 25 Jan 91 18:06:44 GMT
References: <21650@netcom.UUCP> <1991Jan24.125150.4631@cc.helsinki.fi>
Organization: Netcom- The Bay Area's Public Access Unix System {408 241-9760 guest}
Lines: 36

In article <1991Jan24.125150.4631@cc.helsinki.fi> teittinen@cc.helsinki.fi writes:
>In article <21650@netcom.UUCP>, resnicks@netcom.UUCP (Steve Resnick) writes:
>> 
>> I have a problem - I need to trap floating point errors from the floating
>> point hardware. Currently, I am using signal() to do this, but signal doesn't
>> give me some of the information I need.
>
>Have you tried writing your own matherr()-function. It is another "clean"
>way to handle floating point errors and it gets some information that is
>not included in signal (if my memory serves me right).

I have a matherr function - and this does give me detailed information about
who, what, when and where. Problem is, matherr is called by functions in
MATH[insert memory model here].LIB. In the event I do something silly like
double Foo = HUGE_VAL * 10; I will get a floating point overflow, but, since
this is inline in my code, matherr() doesn't get called. Sigh. 

As was pointed out earlier, the NPX (using Intel nomenclature) uses INT 2 on 
an XT. On an AT class machine, the NPX uses int 75H. I don't know yet, the 
state of the PIC, if any, when these interrupts occur, but it sounds as
though I may be spitting in the wind, if the coprocessor does in fact execute
in paralell to the CPU .

Thanx for the info., guys! :)

Cheers!
Steve


-- 
-------------------------------------------------------------------------------
resnicks@netcom.com, stever@octopus.com, steve.resnick@f105.n143.z1.FIDONET.ORG
apple!camphq!105!steve.resnick, {apple|pyramid|vsi1}!octopus!stever
- In real life: Steve Resnick. Flames, grammar and spelling errors >/dev/null
0x2b |~ 0x2b, THAT is the question.
-------------------------------------------------------------------------------