Re: [HACKERS] [GENERAL] division by zero
Bruce Momjian wrote: snip FWIW, this also is a problem with some of the windows ports. For example, 'select 0/0' is unpredictable and can cause the server to gpf and restart. This does not include the SRA port, because I don't have it. I just tested the SRA Win32 threaded port and both SELECT 1/0 and SELECT 0/0 crash the process. I have reported this to Tatsuo. Reported the issue to the Apple guys earlier on today, but haven't heard anything back from them yet. Guess we'll have to wait a few days to find out where things are at in regards to MacOS X. Regards and best wishes, Justin Clift -- My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there. - Indira Gandhi ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [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 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [GENERAL] division by zero
Merlin Moncure [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [GENERAL] division by zero
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 ---|- [EMAIL PROTECTED] | Office: (208)612-INET http://Royer.com/People/Doug |Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [GENERAL] division by zero
Doug Royer wrote: No, try/catch does not trap division by zero unless the underlying implementation throws an error there is nothing to catch. I am absolutely 100% sure that you can catch int/0 with a try catch handler (in c++) on windows platforms (when compiled with ms/borland compiler). All these weird issues are a direct result of windows's dos legacy. Try it and see. Merlin ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [GENERAL] division by zero
Merlin Moncure wrote: Doug Royer wrote: No, try/catch does not trap division by zero unless the underlying implementation throws an error there is nothing to catch. I am absolutely 100% sure that you can catch int/0 with a try catch handler (in c++) on windows platforms (when compiled with ms/borland compiler). All these weird issues are a direct result of windows's dos legacy. Try it and see. That must be a Microsoft extension - it is not standard c++. -- Doug Royer | http://INET-Consulting.com ---|- [EMAIL PROTECTED] | Office: (208)612-INET http://Royer.com/People/Doug |Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards smime.p7s Description: S/MIME Cryptographic Signature
Re: [HACKERS] [GENERAL] division by zero
On Mon, 10 Mar 2003, Tom Lane wrote: Merlin Moncure [EMAIL PROTECTED] 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. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [GENERAL] division by zero
Stephan Szabo [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [GENERAL] division by zero
The big question is how to fix this on Win32. Is a test in the
integer
division routines enough? Is there a signal to catch on Win32?
After fighting with the docs a little bit, here is how to handle an
int/0 in a C application.
#include stdio.h
#include excpt.h
#include windows.h
int HandleException( int iExcept );
int main(int argc, char* argv[])
{
int b = 0;
int a;
puts(hello);
__try
{
puts(in try);
a = 0/b;
}
__except( HandleException(GetExceptionCode()) )
{
puts(in except);
}
puts(world);
}
int HandleException( int iExcept )
{
if (iExcept == EXCEPTION_INT_DIVIDE_BY_ZERO)
{
puts(Handled int/0 exception);
return EXCEPTION_EXECUTE_HANDLER;
}
/* call the system handler and crash */
return EXCEPTION_CONTINUE_SEARCH ;
}
Merlin
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [GENERAL] division by zero
Merlin Moncure [EMAIL PROTECTED] writes:
After fighting with the docs a little bit, here is how to handle an
int/0 in a C application.
__try
{
puts(in try);
a = 0/b;
}
__except( HandleException(GetExceptionCode()) )
{
puts(in except);
}
This is not C.
regards, tom lane
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [GENERAL] division by zero
Hi guys, Was just looking around Google for similar reports of errors and came across this: MacOS X Server Developer Release Notes: Core OS Runtime http://www.geminisolutions.com/WebObjects_4.5/Documentation/Developer/YellowBox/ReleaseNotes/Runtime.html Looks like this is a known problem (as of 1998) and may not have been fixed. Further hits come up when searching on the Apple Developer Connection site too: http://developer.apple.com/cgi-bin/search.pl?q=divide+by+zeronum=10lang=lang_en|lang_zh-CN|lang_fr|lang_de|lang_jaie=utf8oe=utf8 (that should be all one line) And this one looks potentially interesting: http://developer.apple.com/technotes/tn2002/tn2053.html (search in this page for FE_ENABLE_DIVBYZERO) Have asked the member of the Apple MacOS X Server team what he recommends the best way to proceed is. Regards and best wishes, Justin Clift Eric B.Ridge wrote: On Saturday, March 8, 2003, at 11:54 PM, Justin Clift wrote: Tom Lane wrote: snip 2. Consider this Apple's problem and file a bug report. Is there a good place to report errors to Apple for this kind of thing? The best place I can find is: http://developer.apple.com/bugreporter/index.html Unfortunately, there doesn't seem to be a way to query existing reports... If there is, I can't find it. Also, I can't help but wonder why Apple/DarwinTeam handle integer division by zero this way. There must be a reason, which makes me think that [considering] this Apple's problem might not work out for postgres in the end. eric -- My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there. - Indira Gandhi ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [GENERAL] division by zero
On Saturday, March 8, 2003, at 11:54 PM, Justin Clift wrote: Tom Lane wrote: snip 2. Consider this Apple's problem and file a bug report. Is there a good place to report errors to Apple for this kind of thing? The best place I can find is: http://developer.apple.com/bugreporter/index.html Unfortunately, there doesn't seem to be a way to query existing reports... If there is, I can't find it. Also, I can't help but wonder why Apple/DarwinTeam handle integer division by zero this way. There must be a reason, which makes me think that [considering] this Apple's problem might not work out for postgres in the end. eric ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [GENERAL] division by zero
Tom Lane wrote: I checked into this, and indeed OS X 10.2 is behaving funny: integer divide by zero doesn't raise any signal, it just returns a bogus answer. They're within their rights to do so according to the ANSI C spec (wherein division by zero is stated to have undefined behavior). But since other BSD-derived Unixen all seem to raise SIGFPE, I can't help wondering if this shouldn't be considered a bug. FWIW, this also is a problem with some of the windows ports. For example, 'select 0/0' is unpredictable and can cause the server to gpf and restart. This does not include the SRA port, because I don't have it. Merlin ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] [GENERAL] division by zero
Eric B. Ridge [EMAIL PROTECTED] writes: select 1/0; fails as expected on my x86 Linux box, so yer right, it's just my little Mac. I switched because Mac's can divide by zero. I checked into this, and indeed OS X 10.2 is behaving funny: integer divide by zero doesn't raise any signal, it just returns a bogus answer. They're within their rights to do so according to the ANSI C spec (wherein division by zero is stated to have undefined behavior). But since other BSD-derived Unixen all seem to raise SIGFPE, I can't help wondering if this shouldn't be considered a bug. I think we have three possible responses: 1. Put explicit tests for zero into the integer division SQL function routines. 2. Consider this Apple's problem and file a bug report. 3. Both. I don't care for answer #1 alone, because it would only catch zero divides in the specific places we put in tests; internal errors would likely go uncaught. So I think a complaint to Apple is in order. I'm not sure whether to also put in zero-divide guards. Comments? regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
