"Merlin Moncure" <merlin.moncure@rcsonline.com> writes:
> The only other solution is a #ifdef win32 around places that potentially
> use integers in the divisor and do some nasty hacking.
Well, it seems to me that we have two different issues to worry about:
1. There are only about half a dozen places for a user-triggered
division by zero to occur (the div and mod functions for int2, int4,
int8; have I missed anything?). It would not be very painful to insert
if (divisor == 0) elog(ERROR, "Integer division by zero");
before each of those trouble spots. This would have the advantage that
the user would not see a potentially misleading reference to a floating-
point error condition, as he does now on most Unixen because of the
SIGFPE signal.
2. Internal divisions that might accidentally divide by 0. These cases
would all represent programmer error, IMHO, and should never happen.
So probably a core dump is okay --- it's no worse than what happens when
you dereference a pointer incorrectly. Certainly we need not fool
around with Microsoftish C extensions to avoid these.
The only thing that's really bothering me at the moment is the fact that
on Mac OS X, the second case (internal errors) would pass undetected.
This may not be too bad because the same errors *would* get caught on
every other platform, but it's still going to be a handicap to anyone
doing code development on OS X. It'd be like developing on a platform
that doesn't trap null-pointer dereferences :-(. But there's little we
can do about that except pester Apple to upgrade their error trapping.
regards, tom lane