> In article <Pine.LNX.3.91.960424071522.20493A-100000@linux.cs.helsinki.fi>
> you write: |
> |I might as well make this blunt. Sensible people stop reading now.
> |
> |The current behaviour IS NOT GOING TO CHANGE.
> |
> |Sorry.
He's right.
> I may risk the wrath of the Gods, but I am going to give you some
> *very* good reasons why this behavior should be changed.
Yes? Where is it?
> 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.
Actually, a very simple thing to do is putting in a SIGFPE handler. Then
when you get a signal, decide for yourself what you want to do.
> The application in which this is happening is a renderer --
Should the kernel know that? Certainly not.
Is whatever is reasonable for your renderer reasonable for, say, a
spreadsheet? Certainly not.
> BTW, the same problem on the same processor under MS Windows
> does *NOT* happen -- apparently Windows has sensible
> integer-divide-exception handling.
Apparently, Windows' handling of divide-by-zero is as brain damaged as the
rest.
However, this is probably a bit hasty. I should probably check this before
I believe it, when I'm back at work thursday.
I rather suspect even Windows isn't that broken.
MfG Kai