Messages in this thread | | | Date | Thu, 25 Apr 1996 08:13:40 +0300 (EET DST) | From | Linus Torvalds <> | Subject | Re: signal(SIGFPE,SIG_IGN), possible solution? |
| |
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.
With floating point, and full IEEE semantics, the situation is different. The Nan or +-Inf will not just magically go away in further calculations, so if an error happened with some intermediate calculation then it will show up in a sane form in the final answer.
With integer arithmetic, there is no such guarantee.
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?
Linus
| |