[In general reply to interesting answers by Messrs. Williams and Binns:] The potential SIGFPE in my case is optionally raised by a numeric library as part of its error-handling mechanism; its manual expressly suggests installing a signal handler and longjmp()ing back to find out what went wrong. It’s a neat functionality, much more convenient and efficient from the user’s side than if()ing context bits after every op; most people would just do what the manual says, without stopping to think about what would happen in multithreaded code. I guess that’s why Dr. Hipp advises people not to use threads. In this case, the issue is compounded by being a tricky race condition (a) unlikely to manifest itself during any kind of normal testing, (b) requiring precisely a certain cross-thread interaction between seemingly unconnected software components, and (c) severe enough to really trash the stack.
I’m not writing anything multithreaded right now. But next month or next year, the humble little SQL user functions I now make could grow up and get plugged into something bigger. And before I longjmp(), I like to know with certainty where I will land. So I believe I should disable the library’s SIGFPE generation and do an ugly mish-mash of error checks instead. For the archives, though, my original question has not been answered. SQLite itself does not do anything with or to signals; indeed, it does not and should not #include <signal.h>. Therefore, the default behavior on SIGFPE is is “implementation-defined” per C standard; it may be SIG_IGN, or it may cause the computer to halt and catch fire. On Fri, 18 Feb 2011 22:32:07 -0500, Roger Binns <rog...@rogerbinns.com> wrote: > Using builtins I see NULL or errors being returned: > > sqlite> .mode insert > sqlite> select 1/0.0; > INSERT INTO table VALUES(NULL); > sqlite> select abs(-9223372036854775808); > Error: integer overflow > I predict that if I looked at the sources, I’d find that Dr. Hipp made SQLite’s divide operator check for a zero underneath it. But as far as I understand, there is no nontrivial way for SQLite to guarantee it can prevent generating other floating-point exceptions. The foregoing does not show what will happen if SQLite is fed a calculation resulting in a s-NaN, subnormal number, inexact, &c.; and as noted, the default signal handler is implementation-defined. Signed integer overflow is a whole different ball of wax (officially “undefined” behavior including specifically in <stdlib.h> abs(); probably also input-checked in SQLite). Any numerics experts (which I am not) or fp-software gurus care to chime in? *If* I am correct in my inductive hypothesis that the SQLite core may in rare circumstances trip SIGFPE, I have some suggestions as to documenting that—including a clear note for idiots that this is not an SQLite problem, but rather a general platform-/compiler-dependent programming issue which may affect SQLite. Very truly, Samuel Adam ◊ <http://certifound.com/> 763 Montgomery Road ◊ Hillsborough, NJ 08844-1304 ◊ United States Legal advice from a non-lawyer: “If you are sued, don’t do what the Supreme Court of New Jersey, its agents, and its officers did.” http://www.youtube.com/watch?v=iT2hEwBfU1g _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
