Hi,
If we compile sqlite3.c (version 3.7.14) using Microsoft Visual C++ 2010 with
maximum optimization, /Ox, then we experience this problem:
The code in sqlite3VXPrintf is sensitive to numerical optimization. With
optimizations turned on, a number like:
99.999999999999943
*sometimes* is returned as the string:
:0.0
(The first letter is a colon, which has an ASCII value just higher than that of
'9').
And with optimizations turned off, you correctly get the string:
100.0
If you look at the code in that method, you can see that numbers like this can
be problematic, as there is some room for difference between the code that
determines the value for e2 and the code that actually processes it. It is one
of those "At what point does 0.9999999... become 1?" type situations.
One potential fix is to change the code in sqlite3.c (around line 19737 in the
amalgamated version) from:
/* Digits prior to the decimal point */
if( e2<0 ){
*(bufpt++) = '0';
}else{
for(; e2>=0; e2--){
*(bufpt++) = et_getdigit(&realvalue,&nsd);
}
}
To this:
/* Digits prior to the decimal point */
if( e2<0 ){
*(bufpt++) = '0';
}else{
for(; e2>=0; e2--){
char digit = et_getdigit(&realvalue,&nsd);
if (digit == ':'){
*(bufpt++) = '1';
*(bufpt++) = '0';
}
else{
*(bufpt++) = digit;
}
}
}
The latter form will handle the (rare) eventually of numerical round off
causing the first digit of the number trying to be '9'+1, or "10".
Any comments on this code change? Is this a safe fix? Any alternate suggestions
for fixing this in the code?
Can this please be logged as bug? And no, strictly speaking technically it is
perhaps not a bug, but at least a request to review the code in that method and
make it a little more defensive / less vulnerable given situations like this?
Change to code to handle this better, so as to continue the culture of sqlite
working and compiling under just about anything with no problem.
I have played around with the C++ optimization settings to get more
consistency, with little luck, unless you turn it all off (which is
undesirable), and then you still wonder.
Plus it is better to change code to be less vulnerable to such optimizations
anyway.
SQLite is wonderful! One of the greatest open source gems out there ever.
Any thoughts or suggestions would be much appreciated,
Thank you.
---------------------------------------------------------------------------------------------------------------------------------------
This e-mail is confidential and intended only for the individual(s) to whom it
is addressed. If you or your organisation is not an intended recipient of this
e-mail, please notify the sender by replying and do not read or disseminate its
information. Please delete all copies from your system. KBC is liable neither
for the proper or complete transmission of the information contained in this
communication nor for any delay in its receipt. Opinions, conclusions and other
information in this message and attachments that do not relate to the official
business of KBC are neither given nor endorsed by it. Even though the Mimecast
Virus Centre has checked this message for all known viruses, you should carry
out your own virus checks before opening any attachments. Thank you for your
co-operation.
www.kbcat.com-----------------------------------------------------------------------------------------------------------------------------------------
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
