I'm not a god, but I'll give it a try.
> It is interesting in fact that this thread has come up right at
> the same time as I am wrestling with this same problem.
>
> viz: The exception issued by the x86 processor (which is turned
> rather questionably into a SIGFPE) is generated *both* on division
> by zero and on division overflow. The latter happens when you
> divide a 64-bit number by a 32-bit number and the result does not
> fit in 32 bits.
>
> Checking for division by zero is easy, but checking for possible
> overflow is quite difficult and expensive. Trust me.
Right, for a/b -> c, you have to:
log(a) - log(b) < log(2^32) which can be expensive.
> The application in which this is happening is a renderer --
> in other words, if the result is slightly wrong in this case,
> a pixel will appear slightly different (no big deal) but if
> a SIGFPE happens, the program dies, which is really bad.
> As I said, checking for overflow is way time consuming.
> What the kernel really should do is trap the exception, set
> EAX to MAX_INT, and continue with the next instruction.
> This is exactly the same thing that should be done on division
> by zero -- it's equivalent to the floating-point case of returning
> Inf.
Is it possible that you could put in a signal handler for SIGFPE which
would do this for you?
> BTW, the same problem on the same processor under MS Windows
> does *NOT* happen -- apparently Windows has sensible
> integer-divide-exception handling.
Owww, that's asking for it.... When asking the gods to be kind, it is good not
to kick them.....
Honestly, he does have a point. You can set the floating point behavior WRT
IEEE rounding, underflow, etc. Why not an integer policy? If the kernel
exception handler could just skip the offending instruction. Damn CISC
processors with their variable instruction lengths....
Cheers,
David