On Dec 22, 2003, at 6:57 AM, Dan Sugalski wrote:
At 11:44 AM -0800 12/20/03, Jeff Clites wrote:On Dec 20, 2003, at 1:54 AM, Leopold Toetsch wrote:
Jeff Clites <[EMAIL PROTECTED]> wrote:
The issue turns out to be that SIGFPE isn't raised on Mac OS X on divide by zero. If I hack src/core_ops.c to explicitly raise(SIGFPE) in the case of zero divisor then the tests pass, so the exception handling code seems to be working correctly.
Ah, good take. As Perl5 obviously catches div by 0, we probably need some Configure test, if a platform signals int div/0.
I was told that int divide by zero has undefined behavior in C (though it's well-defined for floating-point operations, via IEEE 754), so it might be safest to always do an actual check in parrot (though that's an extra conditional branch around every int divide). What I'm thinking is that for a particular platform the behavior may not be consistent, so an accurate Configure check might be difficult. (Also, having this always directly raise a parrot exception should leave us with less platform-dependent code--e.g. I assume the Windows case wouldn't use signals.)
I don't want to use signals to catch math errors. (Though, amusingly, fatal hardware-type errors like math issues were what signals were originally for. But that's something for another time) It's platform-dependent, as we've seen some platforms don't do it, and worse yet some platforms are somewhat indeterminate as to when the errors get thrown. (The Alpha has fuzzy math exceptions. The "math screwed up" status bit does get set, but it isn't generally checked immediately, and the massively out-of-order execution engine tends to throw them at what looks like odd times)
Math operations that can throw errors should have a wrapper around them to catch the error, either a macro or some ops preprocessing keyword that we can wedge in platform-specific checks for.
Another good reason to not use signals to catch math errors is that it's bad practice for libraries to install signals handlers as part of their basic operation (since signal handlers are global to the application, you unexpectedly affect the global behavior of the app).
And the issue of what happens when we're running threaded and the wrong thread gets the signal. (Figuring out which thread gets notified of a signal in general is going to be... fun)
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
