peter@nuchat.UUCP (Peter da Silva) (03/05/88)
Is there a DeciGel-like program to trap and ignore divide-by-zero errors? they're the most annoying GURUs out, since hardly ever is the best way deal with one to crash the system. -- -- a clone of Peter (have you hugged your wolf today) da Silva `-_-' -- normally ...!hoptoad!academ!uhnix1!sugar!peter U -- Disclaimer: These aren't mere opinions... these are *values*.
papa@pollux.usc.edu (Marco Papa) (03/06/88)
In article <731@nuchat.UUCP> peter@nuchat.UUCP (Peter da Silva) writes: >Is there a DeciGel-like program to trap and ignore divide-by-zero errors? >they're the most annoying GURUs out, since hardly ever is the best way >deal with one to crash the system. Get GOMF. Version 1.0 is PD and is on every BBS. Version 2.0 is commercial and you can get it from HyperTek at (604)939-8235 for $ 39.95. I have been using vesion 1.0 and I love it. -- Marco
peter@nuchat.UUCP (Peter da Silva) (03/07/88)
In article <7433@oberon.USC.EDU>, papa@pollux.usc.edu (Marco Papa) writes: > In article <731@nuchat.UUCP> peter@nuchat.UUCP (Peter da Silva) writes: > >Is there a DeciGel-like program to trap and ignore divide-by-zero errors? ^^^^^^^^^^ > Get GOMF. I have GOMF version 1.0. It only saves me a small fraction of the time. And it doesn't satisfy the second part of my request. A divide-by-zero should only cause a program to trap out if that program's runtime has explicitly requested it. The default behavior should be to silently replace it with an infinity. Numerical Analysis weenies can trap it and do the right thing. The rest of us don't care. -- -- a clone of Peter (have you hugged your wolf today) da Silva `-_-' -- normally ...!hoptoad!academ!uhnix1!sugar!peter U -- Disclaimer: These aren't mere opinions... these are *values*.
papa@pollux.usc.edu (Marco Papa) (03/07/88)
In article <740@nuchat.UUCP> peter@nuchat.UUCP (Peter da Silva) writes: >In article <7433@oberon.USC.EDU>, papa@pollux.usc.edu (Marco Papa) writes: >> In article <731@nuchat.UUCP> peter@nuchat.UUCP (Peter da Silva) writes: >> >Is there a DeciGel-like program to trap and ignore divide-by-zero errors? > ^^^^^^^^^^ >> Get GOMF. > >I have GOMF version 1.0. It only saves me a small fraction of the time. And >it doesn't satisfy the second part of my request. A divide-by-zero should >only cause a program to trap out if that program's runtime has explicitly >requested it. The default behavior should be to silently replace it with >an infinity. Numerical Analysis weenies can trap it and do the right thing. >The rest of us don't care. Let's see if the second time it works :-) GET MANX 3.60a. 3.60a includes a UNIX-like signal call that can trap the following: divide by zero and overflow (SIGFPE) illegal instruction (SIGILL) illegal address or bus error (SIGSEGV) As under UNIX one can trap and jump to a function, or terminate the program (SIG_DFL) or ignore the trap (SIG_IGN). The function can execute exit(), longjump(), or return. The last case will resume the program at the point of interrumption. Does this suit you? -- Marco
peter@nuchat.UUCP (Peter da Silva) (03/10/88)
In article <7457@oberon.USC.EDU>, papa@pollux.usc.edu (Marco Papa) writes: > >> >Is there a DeciGel-like program to trap and ignore divide-by-zero errors? > Let's see if the second time it works :-) GET MANX 3.60a. > 3.60a includes a UNIX-like signal call that can trap the following: > divide by zero and overflow (SIGFPE) > illegal instruction (SIGILL) > illegal address or bus error (SIGSEGV) Wot, no SIGINT or SIGQUIT? Be real easy to redirect _abort() to handle that case... By the way this would be unlikely to help me if it should happen that I was having this problem in something I don't happen to have the source for, now would it? As it turns out, I mainly have this problem while debugging, and I'll be sure to take your suggestion as soon as is practicable... but on the other hand there was nothing in my message to indicate that it was any of my programs I was having the problems with... > Does this suit you? Yep. Another point to Manx. -- -- a clone of Peter (have you hugged your wolf today) da Silva `-_-' -- normally ...!hoptoad!academ!uhnix1!sugar!peter U -- Disclaimer: These aren't mere opinions... these are *values*.
dillon@CORY.BERKELEY.EDU (Matt Dillon) (03/11/88)
:> >> >Is there a DeciGel-like program to trap and ignore divide-by-zero errors? : :> Let's see if the second time it works :-) GET MANX 3.60a. : :> 3.60a includes a UNIX-like signal call that can trap the following: : :> divide by zero and overflow (SIGFPE) :> illegal instruction (SIGILL) :> illegal address or bus error (SIGSEGV) : :Wot, no SIGINT or SIGQUIT? Be real easy to redirect _abort() to handle that :case... SIGFPE, SIGILL, and SIGSEGV are synchronous exceptions. SIGINT and SIGQUIT are asynchronous interrupts. The problem with having traps for SIGINT and SIGQUIT (lets say you defined them as ^C and ^E) is that you could be interrupting a critical library call. Exceptions, on the otherhand, (usually) occur within a user program. -Matt
peter@nuchat.UUCP (Peter da Silva) (03/13/88)
In article ... dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > :Wot, no SIGINT or SIGQUIT? Be real easy to redirect _abort() to handle that > :case... > SIGFPE, SIGILL, and SIGSEGV are synchronous exceptions. SIGINT > and SIGQUIT are asynchronous interrupts. The problem with having traps > for SIGINT and SIGQUIT (lets say you defined them as ^C and ^E) is that > you could be interrupting a critical library call. Exceptions, on the > otherhand, (usually) occur within a user program. Right, but right now what Manx does is call _abort() if it detects any of SIGB_CTRL* have been set when you do a stdio call. It would be easy enough to have it call whatever you've set SIGINT and SIGQUIT to instead. It'd be a step in the right direction. Besides, I'm sure I could get SIGSEGV in a library routine if I tried :->. -- -- a clone of Peter (have you hugged your wolf today) da Silva `-_-' -- normally ...!hoptoad!academ!uhnix1!sugar!peter U -- Disclaimer: These aren't mere opinions... these are *values*.