lkml.org 
[lkml]   [1996]   [Apr]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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


\
 
 \ /
  Last update: 2005-03-22 13:36    [W:0.122 / U:27.448 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site