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