My background is in the DOS/Windows environment, where I've been programming
for the last 15 years. I've been running both DOS and Linux for the past
year (I'm really working hard at learning Linux).
I use Borland's compilers, always have and always will in the DOS world. (I
figure Microsoft's OS's are broken, so their compilers probably are, too.)
The problem is what to do if one ignores an SIGFPE when an integer divide by
zero occurs. Many suggestions have been offered, and in each situation, the
author was right in the context of his own unique situation, with one
exception. Handling it is not something that the kernel should be doing.
Linus was exactly, 100% right when he said:
> 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).
This is why the why the feature is there: so each of you can handle the
problem in your own unique, application specific, manner. There is no right
way for the kernel to ignore a floating point exception. So trap it. Don't
just ignore it. The program that started this whole thread is just plain
silly!
Borland C++ 4.0's manual states:
"When the signal type is SIGFPE, SIGSEGV, or SIGILL, a return from a signal
handler is not advisable if the state of the 8087 is corrupt, the results of
an integer division are wrong, an operation that shouldn't have overflowed
did, a bound instruction failed or an illegal operation was attempted. The
only time a return is reasonable is when the handler alters the registers so
that a reasonable return context exists or the signal type indicates that the
signal was generated explicitly...
Generally in this case you would print an error message and terminate the
program using _exit, exit or abort. If a return is executed under any other
conditions, the program's action will probably be unpredictable upon
resumimg."
It is the PROGRAMMERS RESPONSIBILITY to handle these situations!!!!!
^^^^^^^^^^^ ^^^^^^^^^^^^^^
I personally try to test (in the normal code sequence, not with an exception
handler) before each division if I have any reason to suspect that a 0
divisor is going to rear it's ugly head. And I take care of it before it
happens. It is almost always a fatal error anyway.
One more comment (to Linus):
The question has come up as to whether an integer divide by 0 is really a
SIGFPE, since it's not really a floating point operation. The Borland
compiler has extensions to ANSI C for SIGFPE which call the user handler with
signals FPE_INTDIV0 for a integer divide by 0 and FPE_INTOVFLOW when an
integer operation overflows. I have used them and they work nice. But then
porting to Linux is now a problem because I did use them. (Hey, who knew five
years ago!)
> 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?
NO NO NO. It's fine (ie., correct) the way it is. If I were to suggest any
change at all (and I'm not) I'd go for making a SIGFPE not ignorable.
Regards,
Robert
-- mailto:rwuest@ix.netcom.com Powered by Linux. Any job worth doing is worth doing wrong - while you're learning.