On Sun, Feb 20, 2011 at 6:24 AM, Samuel Adam <a...@certifound.com> wrote: > 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.
Roughly what I recommended. > 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. Libraries in general should not manipulate signal handlers, as it is difficult to do well and always has the potential to conflict with the application (since the application can change handlers at any time, asynchronously to the libraries that care). > 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. Why don't you try it? Nico -- _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
