Re: [sqlite] SQLite version 3.7.5 - code freeze

2011-01-26 Thread Roger Binns
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > A far better solution ... would be to bump > the VFS version number to 3 That is the only solution that will not break any existing code from anyone. ie you have to use VFS 3 to opt in to getting SYNC_OMITTED (probably best delivered to

Re: [sqlite] SQLite version 3.7.5 - code freeze

2011-01-26 Thread Richard Hipp
On Wed, Jan 26, 2011 at 12:20 AM, Roger Binns wrote: > - > A far better solution ... would be to bump > the VFS version number to 3 Suppose we rig the default VFSes so that they return SQLITE_OK for SQLITE_FCNTL_SYNC_OMITTED, instead of SQLITE_ERROR, so that your

Re: [sqlite] SQLite version 3.7.5 - code freeze

2011-01-25 Thread Roger Binns
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/25/2011 08:56 AM, Richard Hipp wrote: >> Thanks for the helpful feedback. Please let us know if you find this >> solution inadequate or if you encounter other problems. A far better solution to this kind of thing is to do them the other way

Re: [sqlite] SQLite version 3.7.5 - code freeze

2011-01-25 Thread Richard Hipp
On Tue, Jan 25, 2011 at 11:31 AM, Roger Binns wrote: > -BEGIN PGP SIGNED MESSAGE- > The issues I have with this file control are: > > - - It is documented as "internal" but my code sees it hence it is now part > of > the external interface of SQLite > You are

Re: [sqlite] SQLite version 3.7.5 - code freeze

2011-01-25 Thread Roger Binns
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/24/2011 09:27 PM, Dan Kennedy wrote: > Does the aspw xFileControl method modify the value of the output > parameter in this case? No. > The idea was that existing VFS implementations would return SQLITE_ERROR > since they do not recognize

Re: [sqlite] SQLite version 3.7.5 - code freeze

2011-01-24 Thread Dan Kennedy
On 01/25/2011 12:20 PM, Roger Binns wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 01/24/2011 06:05 PM, Roger Binns wrote: >> I'm finding custom VFS code is no longer working at all. > > The cause is a new xFileControl operation SQLITE_FCNTL_SYNC which appears to > needlessly

Re: [sqlite] SQLite version 3.7.5 - code freeze

2011-01-24 Thread Roger Binns
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/24/2011 06:05 PM, Roger Binns wrote: > I'm finding custom VFS code is no longer working at all. The cause is a new xFileControl operation SQLITE_FCNTL_SYNC which appears to needlessly duplicate the existing xSync method. Additionally unlike

Re: [sqlite] SQLite version 3.7.5 - code freeze

2011-01-24 Thread Dan Kennedy
On 01/25/2011 04:10 AM, Black, Michael (IS) wrote: > Is this if statement meant to be constant? Or should it be comparing the > requested encoding instead of SQLITE_UTF16NATIVE? > > SQLITE_PRIVATE int sqlite3Utf16ByteLen(const void *zIn, int nChar){ >int c; >unsigned char const *z = zIn;

Re: [sqlite] SQLite version 3.7.5 - code freeze

2011-01-24 Thread Roger Binns
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/24/2011 10:12 AM, Richard Hipp wrote: > Unless serious problems I'm finding custom VFS code is no longer working at all. Mine "inherits" from an existing one overriding or calling the original methods as appropriate. My code for this is

Re: [sqlite] SQLite version 3.7.5 - code freeze

2011-01-24 Thread Richard Hipp
On Mon, Jan 24, 2011 at 3:36 PM, Black, Michael (IS) wrote: > Minor item...I reported this before... > Compiling version 3.7.5...this warning has actually been around a while > though > I can't find anybody reporting it for sqlite3... > > gcc44 -O3 -Wall -fPIC

Re: [sqlite] SQLite version 3.7.5 - code freeze

2011-01-24 Thread Black, Michael (IS)
Around line 59981 sqlite3StrAccumAppend(, zStart, zRawSql-zStart); The zRawSql-zStart is a 64-bit value (on a 64-bit machine) but gets down-converted to int. Seems a little more error checking is appropriate to ensure this doesn't exceed an int. Would be an awfully long SQL string but

Re: [sqlite] SQLite version 3.7.5 - code freeze

2011-01-24 Thread Black, Michael (IS)
SQLITE_PRIVATE int sqlite3Utf16ByteLen(const void *zIn, int nChar){ int c; should be unsigned int c; Otherwise I don't think the macros work right (they become constant expression warnings). Michael D. Black Senior Scientist NG Information Systems Advanced Analytics Directorate

Re: [sqlite] SQLite version 3.7.5 - code freeze

2011-01-24 Thread Black, Michael (IS)
Is this if statement meant to be constant? Or should it be comparing the requested encoding instead of SQLITE_UTF16NATIVE? SQLITE_PRIVATE int sqlite3Utf16ByteLen(const void *zIn, int nChar){ int c; unsigned char const *z = zIn; int n = 0; if( SQLITE_UTF16NATIVE==SQLITE_UTF16BE ){

Re: [sqlite] SQLite version 3.7.5 - code freeze

2011-01-24 Thread Black, Michael (IS)
Minor item...I reported this before... Compiling version 3.7.5...this warning has actually been around a while though I can't find anybody reporting it for sqlite3... gcc44 -O3 -Wall -fPIC -DNO_GETTOD -c sqlite3.c sqlite3.c: In function âfkLookupParentâ: sqlite3.c:55430: warning: assuming

Re: [sqlite] SQLite version 3.7.5 - code freeze

2011-01-24 Thread Marian Cascaval
Here's a first documentation typo: http://www.sqlite.org/draft/c3ref/mprintf.html "_In_ sqlite3_snprintf() routine is similar to "snprintf()" from the standard C library." It should be "_The_ sqlite3_snprintf() routine is similar to ...". Marian Cascaval