>
>
> On Wed, 24 Apr 1996, Ben Wing wrote:
> >
> > 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.
>
> So, what you do is create a signal handler, and then YOU do the fixup if
> you have problems.
>
> "longjump" is your friend - it is meant for problems _exactly_ like this.
> What you do is you do a setjump before the whole calculation, and if you
> get a SIGFPE you longjump out of the signal handler (better use
> sigsetjump and siglongjmp, actually).
>
> Why the h*ll can't people understand?
>
> What is so horribly hard in understanding the fact that this is not a
> kernel issue at all. Why do people insist that the added code should go
> into the KERNEL, when the problem is in your broken programs?
>
> Am I your nanny?
>
> The kernel is there to support user programs, but it's a _resource_
> handler, not a baby feeder. Maybe you should use a real language that
> supports exceptions instead of asking for broken kernels..
>
> > BTW, the same problem on the same processor under MS Windows
> > does *NOT* happen -- apparently Windows has sensible
> > integer-divide-exception handling.
>
> Excellent example. MS Windows is well-known for it's stability and
> predictability. So it happens to get the right asnwer FOR YOU. What if it
> happens to get the wrong answer for somebody who _does_ depend on it?
>
> Did you work on the Pentium division stuff, by any chance?
>
> Really. This isn't even worth discussing. Returning some random number
> for integer division by zero (and yes, 0 or -MAX_INT or whatever are
> _also_ random numbers) is BROKEN BROKEN BROKEN.
This reminds me of the Mutlu autoflamer, that sent random flame mail
every time it encountered the word "Turkey" anywhere, even in
reference to something like "how should I prepare my turkey this
Thanskgiving?"
You've sent this whole long flame, but completely missed the point
that I was *NOT* talking about division by zero, but rather about
overflow -- e.g. if I divide 0xFFFFFFFFFFFFFFFF (a 64-bit number)
by 0xFFFFFFF (a 28-bit number) using the idivl instruction, the
processor issues an exception because the result does not fit into
32 bit, but takes 36 bits. Returning MAX_INT here is NOT random --
it's the closest reasonable approximation.
And yes, I had considered longjmp()ing out of a signal handler.
However, this idivl instruction occurs HUNDREDS, maybe thousands,
of times in the renderer. Can you imagine the pain involved in
ensuring there was a setjmp() everywhere?
Furthermore, there are many places where the added overhead of
a setjmp() would be quite significant.
It is completely out of the question to check for overflow before
each idivl instruction. To check for overflow requires subtracting
the number of bits in the two values, and to compute the number of
bits in a quantity is O(the number of bits in the quantity) and
doing all this would take many many times the time it took to do
the idivl instruction itself.
Do I REALLY have to set up my own signal handler that looked at
the assembly and stepped the program counter over the instruction?
Isn't that more than a bit absurd?
> Trust me, the fact that you have _one_ program that does not care about
> the result of the division is not an argument at all. Are you really
> suggesting that we should make all _other_ programs unsafe too just
> because you have a specific use for this braindamage?
Is it braindamage if I expect that if I say 'signal (SIGFPE, SIG_IGN)'
then the machine will ignore the SIGFPE and continue in its merry
way? If the only way to get this braindamage is to **explicitly
request it**, how can it possibly make all other programs unsafe?
ben