Re: PATCH for loop.c, SIGFPE with bad integer operands on host (linux-)ix86

[torvalds at transmeta dot com (Linus Torvalds)]

In article <7368.933725371@upchuck.cygnus.com>,
Jeffrey A Law  <law@cygnus.com> wrote:
>
>The kernel trap handlers need to be fixed.

Ehh... 

I don't think so. What would you suggest? We silently ignore a integer
division overflow?

That would be rather stupid, don't you think?

>It's a common problem, in fact, I had to fix PA kernels in a similar manner
>a couple times over the years.

It's definitely an application problem, not a kernel problem.  There
might be some way for an application to ask for forgivenness, but this
is not even Linux-specific.  Every x86 UNIX out there probably does the
same. 

What do you expect to happen when you do an integer divide by zero? Do
you expect the kernel to "fix" your user mode bug there too? A divide
overflow isn't that much different (the x86 hardware certainly thinks
that they are identical problems). 

Do you want the kernel to start "fixing" your NULL pointer dereferences
too? HP-UX did that.  It made compiler writers happy because they could
just move dereferences past NULL pointer checks, but it made debugging
hell on earth.  Of course, the HP guys never much seemed to care about
anything but spec numbers anyway, certainly not about anything as
mundane as being usable. 

And a integer divide overflow is no different from that.  Different
languages may require different trap handling, and the kernel cannot
know unless told.  If you "fixed" your PA kernels, then I'm afraid that
you definitely left them in a worse state after the fix than before the
fix.  Probably acceptable at HP, considering that they didn't think they
should trap on NULL either - fits right in.

Note that as with floating point arithmetic, there could certainly be a
protocol to say "ignore integer overflow errors".  But it has to be a
_protocol_, it can't just be the kernel doing so on its own.  And quite
frankly, I don't see why it's needed - the fix for integer divide
overflows is a simple "don't do that, then".  The same it is for integer
division by zero. 

		Linus

PS.  If you really want to fix it up, I would seriously suggest doing it
the same way people fix up FP errors: catch SIGFPE, and decode why the
fault happened, and fix it up in user space.  It's a lot easier to do
that in user space than in kernel space anyway, and it puts the onus of
programming where it properly belongs - with the program that cares.