[sqlite] Setting SQLITE_OMIT_FLOATING_POINT has surprising undocumented consequences
On 14 January 2016 at 22:31, Warren Young wrote: > For no especially good reason, I decided to turn off all SQLite features I?m > not using now and which I have no plans to use in the future. > > My current DB doesn?t use any FP columns, so I rebuild SQLite with > SQLITE_OMIT_FLOATING_POINT and ran ran into a bunch of breakage: > > 1. The (double) cast on line 66942 of the current amalgamation in > valueFromExpr() produces a warning. Most of that block probably should go > away if FP is disabled. http://www.sqlite.org/compile.html#omitfeatures SQLITE_OMIT_xxx options "may only be used when the library is built from canonical source, not from the amalgamation" Regards, Simon
[sqlite] Setting SQLITE_OMIT_FLOATING_POINT has surprising undocumented consequences
On Jan 15, 2016, at 3:11 AM, Simon Davies wrote: > > On 14 January 2016 at 22:31, Warren Young wrote: >> >> I rebuild SQLite with SQLITE_OMIT_FLOATING_POINT and ran ran into a bunch of >> breakage: > > http://www.sqlite.org/compile.html#omitfeatures > > SQLITE_OMIT_xxx options "may only be used when the library is built > from canonical source, not from the amalgamation? Fine: fossil clone http://www.sqlite.org/cgi/src ~/museum/sqlite.fossil mkdir -p ~/src/sqlite/head cd ~/src/sqlite/head fossil open ~/museum/sqlite.fossil cp Makefile.linux-gcc Makefile # edit TOP: the default should be ., not ../sqlite! # edit OPTS: add -DSQLITE_OMIT_FLOATING_POINT rm -f sqlite3.c# just to be sure make ?and the thrust of what I wrote remains true: there?s a bunch of code in SQLite that tries to use double even though this option is enabled. It actually dies trying to build the shell: ./src/shell.c: In function ?timeOfDay?: ./src/shell.c:172:5: warning: passing argument 2 of ?clockVfs->xCurrentTime? from incompatible pointer type [enabled by default] clockVfs->xCurrentTime(clockVfs, ); ^ ./src/shell.c:172:5: note: expected ?sqlite3_int64 *? but argument is of type ?double *? Realize that I?m reporting this mainly as a heads-up to the developers, not because I particularly want this fixed. Every FPU-less platform I?ve ever developed for was too small to run SQLite in the first place. I was just trying to remove code I don?t use. Given that, I see several options: 1. Ignore the known breakage. 2. Declare that SQLite now requires FP, and remove the option. 3. Rework it like I proposed in the previous post: one option for completely FP-free builds, and a separate one to just remove FP features from the supported SQL language: no REAL columns, no likelihood(), no round(), etc. It?s the last option I actually wanted, because in my app, an FP literal must be a bug, so I?d prefer that SQLite refused to accept it. It?s hard to imagine another SQLite data type that someone would want to treat that way, except possibly BLOB. But FP? There are *many* applications where FP is not only not used, but also not *wanted*.
[sqlite] Setting SQLITE_OMIT_FLOATING_POINT has surprising undocumented consequences
For no especially good reason, I decided to turn off all SQLite features I?m not using now and which I have no plans to use in the future. My current DB doesn?t use any FP columns, so I rebuild SQLite with SQLITE_OMIT_FLOATING_POINT and ran ran into a bunch of breakage: 1. The (double) cast on line 66942 of the current amalgamation in valueFromExpr() produces a warning. Most of that block probably should go away if FP is disabled. 2. Similar problem on 138811 in FTS3: the cost estimator uses FP. 3. Setting this implicitly defines SQLITE_OMIT_TRACE, which removes sqlite3_profile(), even though that interface doesn?t use FP. I didn?t look deeply into it, but apparently it does use FP internally. At minimum, this should be documented. It would be better if SQLite decoupled the two reasons to disable FP: a. My processor has no FPU, so I don?t want *any* FP code in sqlite3.o; and b. I don?t use FP in my DB, so I want to disable REAL and related things, but it?s fine if SQLite uses it internally. (Profiling, FTS3, etc.) It?s actually the latter I was expecting when I set this build option. 4. If the current all-or-nothing approach to FP continues, setting this should probably implicitly set SQLITE_RTREE_INT_ONLY. Currently, you get a complaint due to use of double on lines and 156404 and 158887 of the current amalgamation. 5. #4 happens whether you have SQLITE_ENABLE_RTREE defined or not. I couldn?t work out why, but this tells me the r*tree code is being compiled in despite being unasked-for.
