Robert, I re-verified using your option set, and I still get the same problem. there is clearly something wrong here, and it is not easy to track down. I wonder if you could help me with this. Shall we take this off-line, so that we dont clutter the list, and report back when done ? I would really appreciate your help. since your e-mail is not visible, I cannot contact you directly. would you drop me a line at mikecar<theUsualAtSymbol>Singular.gr btw, I noticed something in your configuration : the option THREADSAFE is set, but NOT set to 1 AFAIK, the source uses this : #if defined(THREADSAFE) && THREADSAFE
which probably means you are compiling with no thread safety (does not make any difference for my issue, but you may want to know) ________________________________ From: Robert Simpson [mailto:[EMAIL PROTECTED] Sent: Wed 08-Nov-06 6:27 PM To: sqlite-users@sqlite.org Subject: RE: [sqlite] weird (and dangerous) bug in Microsoft Compiler I compiled everything from bare source myself. I maintain the ADO.NET 2.0 wrapper. > -----Original Message----- > From: mike cariotoglou [mailto:[EMAIL PROTECTED] > Sent: Wednesday, November 08, 2006 9:18 AM > To: sqlite-users@sqlite.org > Subject: Re: [sqlite] weird (and dangerous) bug in Microsoft Compiler > > did you also compile the ado .net wrapper ? > > ----- Original Message ----- > From: "Robert Simpson" <[EMAIL PROTECTED]> > To: <sqlite-users@sqlite.org> > Sent: Wednesday, November 08, 2006 4:57 PM > Subject: RE: [sqlite] weird (and dangerous) bug in Microsoft Compiler > > > >I tried that same SELECT statement in 3 builds of SQLite on > VS2005. The > > code was called from C# using the ADO.NET 2.0 wrapper, and > I got 10 all 3 > > times. I tried /fp:fast, /fp:strict and /fp:precise > > > > The rest of the build options were: > > > > AdditionalOptions="/GS-" > > Optimization="2" > > FavorSizeOrSpeed="1" > > > > > PreprocessorDefinitions="WIN32;NDEBUG;_WINDOWS;_USRDLL;_CRT_SE > CURE_NO_DEPREC > > > ATE;NO_TCL;THREADSAFE;SQLITE_HAS_CODEC;SQLITE_ENABLE_COLUMN_ME > TADATA;SQLITE_ > > ENABLE_FTS1" > > StringPooling="true" > > ExceptionHandling="0" > > BufferSecurityCheck="false" > > EnableFunctionLevelLinking="true" > > RuntimeTypeInfo="false" > > > > > >> -----Original Message----- > >> From: mike cariotoglou [mailto:[EMAIL PROTECTED] > >> Sent: Wednesday, November 08, 2006 5:27 AM > >> To: sqlite-users@sqlite.org > >> Subject: [sqlite] weird (and dangerous) bug in Microsoft Compiler > >> > >> hello to all. I wish to report some quirks I discovered with > >> floating point > >> and > >> ROUND() function, while looking into a problem reported by my > >> development > >> team wrt > >> to sqlite handling of above function. > >> > >> first of all, let me state that I understand the issues > with inexact > >> floating point > >> representations, so let us not go into discussions about > which is the > >> "correct" > >> interpretation of 9.95. however, a given implementation > >> should at least be > >> consistent > >> wrt to this. > >> > >> my tests have shown that, for the following statement: > >> > >> select ROUND(9.95,1) > >> > >> the command-line sqlite3.exe (v 3.3.8) returns 10.0 > >> OTOH, the compiled DLL that can be downloaded from the sqlite > >> site returns > >> 9.9 ! > >> (as a reference, both MS SQL and ORACLE return 10.0) > >> > >> What gives ? is the result dependent on compilation options, > >> and if so, > >> which ? > >> > >> trying to investigate this issue, I compiled the dll locally > >> (3.3.8), using > >> Microsoft > >> Visual Studio 2005, and came across a beauty : > >> > >> the dll compiled with MSVC, using default options more or > >> less, gives 0.0 > >> (yes, zero) > >> > >> I pulled my hair out over this for some hours, and > discovered that : > >> > >> a. the floating point optimizer in MSVC has a bug, which is > >> triggered when > >> you use the > >> optimization setting /fp:precice (which is the default), and > >> gives the above > >> erroneous > >> result. > >> > >> b. you can get the correct behavior by speifying optimization > >> as /fp:strict > >> > >> Clearly, this is a problem with the microsoft compiler. > >> however, trying to > >> avoid future > >> issues, I suggest that somebody which is conversant in C > >> (which is not me), > >> try to find > >> the sqlite3 source construct that triggers this bug, and > >> re-writes the code > >> so that it > >> is not optimization-sensitive. I tracked the problem down > >> somewhere in the > >> vxprintf function > >> in the print.c source file. It is quite difficult to pin the > >> problem down, > >> because: > >> > >> the problem goes away when you build in debug mode, because > >> optimizations > >> are turned off. > >> Even if you force some optimizations by hand, in debug mode, > >> the compiler > >> will start > >> using floating-point stack and registers for variables. > the debugger, > >> however,does not seem > >> to understand about these optimizations, so, inspecting the > >> variables gives > >> you the wrong > >> results. (how people manage to work in this environment is > >> beyond me, my > >> good ole delphi > >> never does thigs like this!) > >> > >> Could someone please verify my findings, especially the > one about the > >> correct setting for > >> MSVC to compile the dll ? and, assuming the above is > >> verified, I think we > >> should add > >> a warning in the WIKI for poor souls who will try to compile > >> using MS Visual > >> Studio 2005 > >> in the future ! > >> > >> PS > >> when testing, pls note that the value 9.95 is a "magic" > >> value, due to the > >> way the > >> code is written in print.c. AFAIK it is the only value > >> manifesting the > >> compiler bug, > >> probably due to the way that the imput to ROUND() is compared > >> to the value > >> "10.0" in > >> various points in the code. > >> > >> > >> > >> -------------------------------------------------------------- > >> --------------- > >> To unsubscribe, send email to [EMAIL PROTECTED] > >> -------------------------------------------------------------- > >> --------------- > >> > > > > > > > > > > > -------------------------------------------------------------- > --------------- > > To unsubscribe, send email to [EMAIL PROTECTED] > > > -------------------------------------------------------------- > --------------- > > > > > > > > > > -------------------------------------------------------------- > --------------- > To unsubscribe, send email to [EMAIL PROTECTED] > -------------------------------------------------------------- > --------------- > ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
