Two cases: ((float)x)/0.0 should probably yield NaN if SIGFPE is
ignored. ((int)x)/0 should return... MAX_INT? 0? does anything make
sense?
Actually, I just tried a test case. With all signals at default,
0.0/0.0 yields NaN without exception, 1.0/0.0 yields Inf without
exception, and 0/0 and 1/0 both yielded "Floating point exception"s.
> 2) The important thing is, if SIGFPE is signalled by the FPU a bit more
> exact, so we can be sure, that we got SIGFPE because of x/0 or other
> causes.
The FPU is not invoked on a integer divide, so it shouldn't trigger a
SIGFPE in this case.
> 3) The FPU has a stack architecture, that much I know about Intel FPU's :)
> 4) Now we could just pop two arguments from the stack, and because we
> probably know that it will execute the fdiv instruction again, we push
> say 0.0 100.0 on the stack and reexecute the fdiv. It should now
> return a 0.0/100.0==0.0 and all is well.
On my 486, at least, the FPU is already returning a workable value for
a division by zero. It's the integer case that is questionable, and
difficult.
I tested the following cases: (all with signals at defaults)
Test Result
0/0 core dump
1/0 core dump
0.0/0.0 NaN
1.0/0.0 Inf
(int)0.0/0.0 0
(int)1.0/0.0 0
So it seems that returning a 0 for an integer divide-by-zero could be
considered "reasonable".
>
> It sounds bit weird, but if the error condition of the FPU is precise
> enough, one could handle this one :)
>
> Linus, what do you thing?
>
> Andreas
--
Buddha Buck bmbuck@acsu.buffalo.edu
"She was infatuated with their male prostitutes, whose members were
like those of donkeys and whose seed came in floods like that of
stallions." -- Ezekiel 23:20