Обсуждение: Re: [GENERAL] division by zero

Tom Lane wrote:
> This is not C.

I can't argue that; but it will compile on a C compiler on the Microsoft
platform.  I'm not sure if you were answering tongue-in-cheek, so for
the benefit of the group:

__try and __except, as far as I can tell are the only way to gracefully
handle certain events.  There is also a __finally.  This is very much a
Microsoft hack to C and not C++.

GetExceptionCode() is from the win32 api.

In C++, you get to use the much more standard try/catch system.

Katie mentioned a while back using CWinApp from MFC for the windows
port.  I advised against this based on it requiring a C++ compiler and
the MFC libs.  However, if the win32 port is going that route maybe
introducing a little c++ exception handling might be the best solution
to the int/0 problem.

Barring that, it comes down to a choice of two not very pleasant
scenarios: either adopting the __try abomination or standardizing on
non-microsoft implementation of the C run time.  You can forget using
anything from MFC in this case.

The only other solution is a #ifdef win32 around places that potentially
use integers in the divisor and do some nasty hacking.  I would prefer
to use some type of signaling or 'exception' handling to that.   The end
justifies the means, I suppose.

Merlin

"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

Merlin Moncure wrote:
>
> 
> __try and __except, as far as I can tell are the only way to gracefully
> handle certain events.  There is also a __finally.  This is very much a
> Microsoft hack to C and not C++.
> 
> GetExceptionCode() is from the win32 api.
> 
> In C++, you get to use the much more standard try/catch system.

No, try/catch does not trap division by zero unless the underlying
implementation throws an error there is nothing to catch.

On Unix's trap for signal SIGFPE - standard POSIX.

-- 
 Doug Royer                     |   http://INET-Consulting.com
-------------------------------|-----------------------------Doug@Royer.com                 | Office: (208)612-INET
http://Royer.com/People/Doug  |    Fax: (866)594-8574                                |   Cell: (208)520-4044
 
                We Do Standards - You Need Standards

On Mon, 10 Mar 2003, Tom Lane wrote:

> "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

It's unlikely to come up in practice, but chardiv as well for "char".

Stephan Szabo <sszabo@megazone23.bigpanda.com> writes:
>> 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

> It's unlikely to come up in practice, but chardiv as well for "char".

Good catch --- thanks!
        regards, tom lane