On Fri, Sep 14, 2012 at 4:49 PM, van der Merwe, Ben
<bvanderme...@kbcat.com>wrote:
> 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
>
Can you provide a test case where this actually happens?
>
> (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
>
--
D. Richard Hipp
d...@sqlite.org
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
