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