Re: [sqlite] Regarding the whole C89/C90 language compliance debacle ...
Op za 23 nov. 2019 om 23:27 schreef Dennis Clarke: > /usr/local/build/sqlite-src-3300100_Oracle_sparc64vii+.005/src/tclsqlite.c: > "/usr/local/build/sqlite-src-3300100_Oracle_sparc64vii+.005/src/tclsqlite.c", > line 2624: warning: argument #3 is incompatible with prototype: > prototype: pointer to long : "/usr/local/include/tclDecls.h", > line 2866 Line 2611 of tclsqlite.c reads: sqlite3_int64 mxSize = 0; this should have been Tcl_WideInt mxSize = 0; Tcl_WideInt is guaranteed to be at least a 64-bit type, but it might be "long" or "long long" dependant on Tcl version or platform. So, the warning is harmless, understandable, and easy to fix. Regards, Jan Nijtmans ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Segfault when using FILTER (WHERE) referencing aliases from a subquery
Op do 10 okt. 2019 om 15:15 schreef Jan Nijtmans: > > Op do 10 okt. 2019 om 15:06 schreef Jose Isaias Cabrera: > > > Simon Charette, on Tuesday, October 8, 2019 08:00 PM, wrote... > > > > > > > > While trying to enable support for FILTER (WHERE) on SQLite 3.30 for > > > > the Django ORM we discovered a crash that can be reduced to the > > > > following > > > I am sorry, Simon. You are correct. In Windows sqlite3 just disappears. :-) > > On Cygwin: > > $ sqlite3 > SQLite version 3.30.0 2019-10-04 15:03:17 > Enter ".help" for usage hints. > Connected to a transient in-memory database. > Use ".open FILENAME" to reopen on a persistent database. > sqlite> CREATE TABLE item (id int, price int); > sqlite> INSERT INTO item (id, price) VALUES (1, 1); > sqlite> SELECT COUNT(id) FILTER (WHERE double_price > 42) FROM (SELECT > id, (price * 2) as double_price FROM item); > Segmentation fault (core dumped) > > Indeed, something is wrong there! > > Regards, > Jan Nijtmans So, the crash happens here: <https://www.sqlite.org/src/artifact/e1d8ac7102f3f283?ln=530> ??? Thread 1 "sqlite3" received signal SIGSEGV, Segmentation fault. sqlite3VdbeExec (p=p@entry=0x600094450) at /usr/src/debug/sqlite3-3.30.0-1/sqlite3.c:21673 21673 if( sqlite3GlobalConfig.bLocaltimeFault ) pX = 0; (gdb) stacktrace (gdb) backtrace #0 sqlite3VdbeExec (p=p@entry=0x600094450) at /usr/src/debug/sqlite3-3.30.0-1/sqlite3.c:21673 #1 0x0003e45bdb70 in sqlite3Step (p=0x600094450) at /usr/src/debug/sqlite3-3.30.0-1/sqlite3.c:82993 #2 sqlite3_step (pStmt=pStmt@entry=0x600094450) at /usr/src/debug/sqlite3-3.30.0-1/sqlite3.c:17522 #3 0x000100413694 in exec_prepared_stmt (pStmt=0x600094450, pArg=0xb630) at /usr/src/debug/sqlite3-3.30.0-1/shell.c:11410 #4 shell_exec (pArg=pArg@entry=0xb630, zSql=, zSql@entry=0x60007f200 "SELECT COUNT(id) FILTER (WHERE double_price > 42) FROM (SELECT id, (price * 2) as double_price FROM item);", pzErrMsg=pzErrMsg@entry=0xb3e8) at /usr/src/debug/sqlite3-3.30.0-1/shell.c:11715 #5 0x000100414afd in runOneSqlLine (p=p@entry=0xb630, zSql=zSql@entry=0x60007f200 "SELECT COUNT(id) FILTER (WHERE double_price > 42) FROM (SELECT id, (price * 2) as double_price FROM item);", in=0x0, startline=startline@entry=3) at /usr/src/debug/sqlite3-3.30.0-1/shell.c:18268 #6 0x00010041f346 in process_input (p=p@entry=0xb630) at /usr/src/debug/sqlite3-3.30.0-1/shell.c:18368 #7 0x00010042133f in main (argc=1, argv=0xcc40) at /usr/src/debug/sqlite3-3.30.0-1/shell.c:19142 ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Segfault when using FILTER (WHERE) referencing aliases from a subquery
Op do 10 okt. 2019 om 15:06 schreef Jose Isaias Cabrera: > > Simon Charette, on Tuesday, October 8, 2019 08:00 PM, wrote... > > > > > > While trying to enable support for FILTER (WHERE) on SQLite 3.30 for > > > the Django ORM we discovered a crash that can be reduced to the > > > following > I am sorry, Simon. You are correct. In Windows sqlite3 just disappears. :-) On Cygwin: $ sqlite3 SQLite version 3.30.0 2019-10-04 15:03:17 Enter ".help" for usage hints. Connected to a transient in-memory database. Use ".open FILENAME" to reopen on a persistent database. sqlite> CREATE TABLE item (id int, price int); sqlite> INSERT INTO item (id, price) VALUES (1, 1); sqlite> SELECT COUNT(id) FILTER (WHERE double_price > 42) FROM (SELECT id, (price * 2) as double_price FROM item); Segmentation fault (core dumped) Indeed, something is wrong there! Regards, Jan Nijtmans ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Prebuilt Windows x86 binary missing symbols per sqlite3.def
2017-06-03 20:22 GMT+02:00 Acer Yang: > Sqlite version is 3190220. > x86 and x64 prebuilt Windows binaries are downloaded from > https://www.sqlite.org/download.html > > I compared sqlite3.def files with sort and diff tools. > Some missing symbols as of x86 def file are listed below. > > sqlite3_data_directory > sqlite3_fts5_may_be_corrupt > sqlite3_temp_directory > sqlite3_version > > That should cause link errors per .lib created from the .def file. Reported and answered before. See: <http://sqlite.1065341.n5.nabble.com/sqlite3-def-mismatch-for-Windows-x86-and-x64-dll-td93694.html> Regards, Jan Nijtmans ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Win 10 Anniv. Ed. lifts the MAX_PATH 260 limitation
2017-03-30 11:23 GMT+02:00 Rail Jon Rogut: > Windows 10 Anniversary Edition allows the user to remove the 260 character > limitation in MAX_PATH — any thoughts on updating the code to handle longer > paths? Current SQLite can already do that, no need for Windows 10 even, just use the "win32-longpath" VFS, and prefix all paths with a special prefix. My personal opinion is that this is clumsy, it would be much easier for if SQLite added this special prefix internally without the user noticing. Actually ... I have a patch for SQLite doing exactly that. If someone is interested, just let me know, I'm happy to provide this patch to the SQLite developers, or anyone else interested. Regards, Jan Nijtmans ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] SQLITE_ENABLE_UPDATE_DELETE_LIMIT (Was: Patch Etiquette)
2017-02-06 23:25 GMT+01:00 Ziemowit Laski:
> Here is my approach to the SQLITE_ENABLE_UPDATE_DELETE_LIMIT problem. [If
> the attachment does not arrive intact, please let me know.]
Hi Ziemowit,
I tried your patch, and it works fine! Below is an additional patch, which makes
the resulting amalgamation much smaller (from 202734 to 202415 lines, while
the original amalgamation was 201287 lines). The reason for this reduction is
that your amalgamation contains 321 segments which look like:
#ifndef SQLITE_ENABLE_UPDATE_DELETE_LIMIT
#line 3288 "parse.c"
#else /* SQLITE_ENABLE_UPDATE_DELETE_LIMIT */
#line 3290 "parse.c"
#endif /* SQLITE_ENABLE_UPDATE_DELETE_LIMIT */
This is not really useful, since the only difference is the line
number. If both "parse.c"
versions contain the same line numbering, that helps in the diff size.
Thank you for your idea!
Regards,
Jan nijtmans
Index: src/parse.y
==
--- src/parse.y
+++ src/parse.y
@@ -748,10 +748,11 @@
%ifndef SQLITE_ENABLE_UPDATE_DELETE_LIMIT
cmd ::= with(C) DELETE FROM fullname(X) indexed_opt(I) where_opt(W). {
sqlite3WithPush(pParse, C, 1);
sqlite3SrcListIndexedBy(pParse, X, );
sqlite3DeleteFrom(pParse,X,W);
+ /* for alignment */
}
%endif
%type where_opt {Expr*}
%destructor where_opt {sqlite3ExprDelete(pParse->db, $$);}
@@ -776,10 +777,11 @@
where_opt(W). {
sqlite3WithPush(pParse, C, 1);
sqlite3SrcListIndexedBy(pParse, X, );
sqlite3ExprListCheckLength(pParse,Y,"set list");
sqlite3Update(pParse,X,Y,W,R);
+ /* for alignment */
}
%endif
%type setlist {ExprList*}
%destructor setlist {sqlite3ExprListDelete(pParse->db, $$);}
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Patch Etiquette
2017-02-05 21:14 GMT+01:00 Ziemowit Laski:
> I have another patch in the works which will make
> SQLITE_ENABLE_UPDATE_DELETE_LIMIT directly accessible from the amalgamation,
> but am reluctant to submit it.
Well, I submitted such a patch already, some half year ago. You can
find the full thread here:
<http://sqlite.1065341.n5.nabble.com/ENABLE-UPDATE-DELETE-LIMIT-td90381.html>
Feel free to try this patch (see my message Jul 12, 2016; 11:14am in
this thread)
Regards,
Jan Nijtmans
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] sqlite3.def mismatch for Windows x86 and x64 dll
2017-02-04 10:49 GMT+01:00 Rengui Xie: > Hi dear sqlite developers, > > In the downlaod page for "Precompiled Binaries for Windows", the > sqlite3.def EXPORTS for x86 and x64 dll are not the same, x64 dll have 4 > more export functions: > - sqlite3_data_directory > - sqlite3_fts5_may_be_corrupt > - sqlite3_temp_directory > - sqlite3_version Actually, those are not functions, those are external symbols. Windows Dll's have problems exporting data symbols, that why the mingw-built x86 dll doesn't have them exported. Later Microsoft compilers can handle them fine, that's why the VC-built x64 dll exports them. > I assume x86 and x64 dll shall have the same EXPORTS. > This issue, if it is, exists in latest v3.16.2 and earlier v3.13.0 (maybe > even more earlier version, I did not check more old version). None of those 4 symbols are expected to be used from applications, so whether those are exported or not doesn't really matter. Regards, Jan Nijtmans ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] can't open db when path length extends 512 characters (on linux)
2017-01-30 19:37 GMT+01:00 Dan Kennedy: > On 01/31/2017 12:48 AM, Nir Paz wrote: >> Linux doesn't have that limit, my thought is to change the define of >> MAX_PATHNAME, is there a better option? > > I don't think there is a better way to do that. Define MAX_PATHNAME to > something and see how it goes. > > There is one very subtle problem that we know of: > >http://www.sqlite.org/src/artifact/ff1232b3088a3?ln=2771-2775 Well, starting with this commit: <http://www.sqlite.org/src/info/2e8a9ca9d3d6efdd> the default page size is now 4096. So I don't think the risk is really big. Upgrading to 1024 (or even 4096) should be no problem. See also: <https://www.sqlite.org/pragma.html#pragma_page_size> Regards, Jan Nijtmans ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] tclsqlite 64-bit bug [Was: extension to run bash]
2017-01-12 3:04 GMT+01:00 Warren Young:
> In fact, one improvement made to SQLite a few years ago was to switch it from
> using native Windows file locking when built under Cygwin to use POSIX or BSD
> locking mechanisms, so that two programs built under Cygwin that both used
> SQLite would get the advisory locking semantics they expect, not the
> mandatory locking semantics Windows gives you by default. (It’s more
> complicated than that, but I don’t want to go deeper into it here.)
Yeah ... I'm slowly trying to submit all portability issues I discover
back to the SQLite developers, so far with little success.
For example, the following patch fixes possible crashes in
error-handling in 64-bit builds (not Cygwin-specific). Explanation:
On 64-bit builds '0' is a 32-bit integer, but Tcl_AppendResult()
expects a NULL-pointer as last element which is 64-bit.
Any chance for this to be in the next SQLite release?
Thanks!
Jan Nijtmans
===
$ fossil diff
Index: src/tclsqlite.c
==
--- src/tclsqlite.c
+++ src/tclsqlite.c
@@ -2534,11 +2534,11 @@
for(i=3; i<(objc-1); i++){
const char *z = Tcl_GetString(objv[i]);
int n = strlen30(z);
if( n>2 && strncmp(z, "-argcount",n)==0 ){
if( i==(objc-2) ){
- Tcl_AppendResult(interp, "option requires an argument: ", z, 0);
+ Tcl_AppendResult(interp, "option requires an argument: ",
z, (char *)0);
return TCL_ERROR;
}
if( Tcl_GetIntFromObj(interp, objv[i+1], ) ) return TCL_ERROR;
if( nArg<0 ){
Tcl_AppendResult(interp, "number of arguments must be non-negative",
@@ -2549,11 +2549,11 @@
}else
if( n>2 && strncmp(z, "-deterministic",n)==0 ){
flags |= SQLITE_DETERMINISTIC;
}else{
Tcl_AppendResult(interp, "bad option \"", z,
-"\": must be -argcount or -deterministic", 0
+"\": must be -argcount or -deterministic", (char *)0
);
return TCL_ERROR;
}
}
@@ -3206,11 +3206,11 @@
if( rc==SQLITE_OK ){
Tcl_Obj *pObj;
pObj = Tcl_NewStringObj((char*)sqlite3_value_text(pValue), -1);
Tcl_SetObjResult(interp, pObj);
}else{
- Tcl_AppendResult(interp, sqlite3_errmsg(pDb->db), 0);
+ Tcl_AppendResult(interp, sqlite3_errmsg(pDb->db), (char *)0);
return TCL_ERROR;
}
}
}
#endif /* SQLITE_ENABLE_PREUPDATE_HOOK */
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] ENABLE_UPDATE_DELETE_LIMIT
2016-07-12 11:03 GMT+02:00 Chris Brody:
> Personally I would really like to see this. Can you show the patch somewhere?
Here is the patch. I'm not sure that the SQLite mailing list accepts
attachments,
but your private mail surely does. The patch is generated against current
SQLite trunk.
Regards,
Jan Nijtmans
Index: src/parse.y
==
--- src/parse.y
+++ src/parse.y
@@ -735,54 +735,56 @@
limit_opt(A) ::= LIMIT expr(X) COMMA expr(Y).
{A.pOffset = X.pExpr; A.pLimit =
Y.pExpr;}
/// The DELETE statement /
//
-%ifdef SQLITE_ENABLE_UPDATE_DELETE_LIMIT
cmd ::= with(C) DELETE FROM fullname(X) indexed_opt(I) where_opt(W)
orderby_opt(O) limit_opt(L). {
sqlite3WithPush(pParse, C, 1);
sqlite3SrcListIndexedBy(pParse, X, );
+#if defined(SQLITE_ENABLE_UPDATE_DELETE_LIMIT) &&
!defined(SQLITE_OMIT_SUBQUERY)
W = sqlite3LimitWhere(pParse, X, W, O, L.pLimit, L.pOffset, "DELETE");
- sqlite3DeleteFrom(pParse,X,W);
-}
-%endif
-%ifndef SQLITE_ENABLE_UPDATE_DELETE_LIMIT
-cmd ::= with(C) DELETE FROM fullname(X) indexed_opt(I) where_opt(W). {
- sqlite3WithPush(pParse, C, 1);
- sqlite3SrcListIndexedBy(pParse, X, );
+#else
+ if( O || L.pLimit ){
+sqlite3ErrorMsg(pParse, "%s on DELETE not supported", O?"ORDER
BY":"LIMIT");
+sqlite3ExprDelete(pParse->db, W);
+sqlite3ExprListDelete(pParse->db, O);
+sqlite3ExprDelete(pParse->db, L.pLimit);
+sqlite3ExprDelete(pParse->db, L.pOffset);
+W = 0;
+ }
+#endif
sqlite3DeleteFrom(pParse,X,W);
}
-%endif
%type where_opt {Expr*}
%destructor where_opt {sqlite3ExprDelete(pParse->db, $$);}
where_opt(A) ::= .{A = 0;}
where_opt(A) ::= WHERE expr(X). {A = X.pExpr;}
// The UPDATE command
//
-%ifdef SQLITE_ENABLE_UPDATE_DELETE_LIMIT
cmd ::= with(C) UPDATE orconf(R) fullname(X) indexed_opt(I) SET setlist(Y)
where_opt(W) orderby_opt(O) limit_opt(L). {
sqlite3WithPush(pParse, C, 1);
sqlite3SrcListIndexedBy(pParse, X, );
sqlite3ExprListCheckLength(pParse,Y,"set list");
+#if defined(SQLITE_ENABLE_UPDATE_DELETE_LIMIT) &&
!defined(SQLITE_OMIT_SUBQUERY)
W = sqlite3LimitWhere(pParse, X, W, O, L.pLimit, L.pOffset, "UPDATE");
- sqlite3Update(pParse,X,Y,W,R);
-}
-%endif
-%ifndef SQLITE_ENABLE_UPDATE_DELETE_LIMIT
-cmd ::= with(C) UPDATE orconf(R) fullname(X) indexed_opt(I) SET setlist(Y)
-where_opt(W). {
- sqlite3WithPush(pParse, C, 1);
- sqlite3SrcListIndexedBy(pParse, X, );
- sqlite3ExprListCheckLength(pParse,Y,"set list");
+#else
+ if( O || L.pLimit ){
+sqlite3ErrorMsg(pParse, "%s on UPDATE not supported", O?"ORDER
BY":"LIMIT");
+sqlite3ExprDelete(pParse->db, W);
+sqlite3ExprListDelete(pParse->db, O);
+sqlite3ExprDelete(pParse->db, L.pLimit);
+sqlite3ExprDelete(pParse->db, L.pOffset);
+W = 0;
+ }
+#endif
sqlite3Update(pParse,X,Y,W,R);
}
-%endif
%type setlist {ExprList*}
%destructor setlist {sqlite3ExprListDelete(pParse->db, $$);}
setlist(A) ::= setlist(A) COMMA nm(X) EQ expr(Y). {
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] ENABLE_UPDATE_DELETE_LIMIT
2016-07-11 17:23 GMT+02:00 Richard Hipp:
> Yes. ENABLE_UPDATE_DELETE_LIMIT makes changes to the LALR(1) parser
> tables which cannot be #ifdef-ed out. So there is not a convenient
> way to turn that feature off and on at compile-time except to rerun
> the Lemon parser generator, which basically means rebuilding from
> canonical sources.
Actually, it is very well possible to build an amalgamation which can
be built with or without ENABLE_UPDATE_DELETE_LIMIT, and
functions fine as expected both ways without rerunning Lemon. If you
are interested in a patch which demonstrates this, I'm happy to provide that.
Regards,
Jan Nijtmans
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Problem loading sqlite3.dll on Windows XP
2016-05-25 13:35 GMT+02:00 Costache, Catalin <catalin.costa...@vector.com>: > Hi, > > I am using the provided sqlite3.dll from the download section which causes > problems in Windows XP. > > Our application uses a dynamic dll which is statically linked to sqlite3.dll > (32 bit) using a lib generated from the dll and def file. On Windows 7 there > is no problem, but on windows XP when the application tries to load the > dynamic dll using LoadLibrary I get the error code 127 (ERROR_PROC_NOT_FOUND) > and I have no idea what this means. Dependency Walker shows no problem with > sqlite3.dll. > > Do you know if there are any issues regarding Windows XP? You could try this build, done with mingw-w64 (32-bit): https://sourceforge.net/projects/cyqlite/files/3.13/sqlite-dll-win32-x86-313.zip Microsoft's latest compilers have known issues with Windows XP Regards, Jan Nijtmans ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] Use of DELETE LIMIT OFFSET with ENABLE_UPDATE_DELETE_LIMIT
2015-12-19 21:57 GMT+01:00 Jeremy Boy :
> I would like to use the optional LIMIT and ORDER BY clause for DELETE
> statements in SQLite. I can verify that SQLite was built with
> SQLITE_ENABLE_UPDATE_DELETE_LIMIT:
This doesn't work when sqlite is buillt from the amalamation, which is
clearly stated
in the docs. You need to build it from the sources, then it will work.
The problem is
that the produced amalgamation is different depending on this flag.
My solution would be the patch below (to the SQLite sources). With this
patch in place, the resulting amalgamation can be build either with or without
SQLITE_ENABLE_UPDATE_DELETE_LIMIT, both work as expected. The
produced amalgamation doesn't depend on the SQLITE_ENABLE_UPDATE_DELETE_LIMIT
flag any more.
I'm donating this patch to the public domain, in case anyone is interested
Needless to say: All unit-test (in the SQLite sources) run fine when
this patch is applied.
Could I add this to the 2016 wish-list?;-)
Regards,
Jan Nijtmans
===
--- src/parse.y
+++ src/parse.y
@@ -740,54 +740,56 @@
limit_opt(A) ::= LIMIT expr(X) COMMA expr(Y).
{A.pOffset = X.pExpr; A.pLimit
= Y.pExpr;}
/// The DELETE statement /
//
-%ifdef SQLITE_ENABLE_UPDATE_DELETE_LIMIT
cmd ::= with(C) DELETE FROM fullname(X) indexed_opt(I) where_opt(W)
orderby_opt(O) limit_opt(L). {
sqlite3WithPush(pParse, C, 1);
sqlite3SrcListIndexedBy(pParse, X, );
+#if defined(SQLITE_ENABLE_UPDATE_DELETE_LIMIT) &&
!defined(SQLITE_OMIT_SUBQUERY)
W = sqlite3LimitWhere(pParse, X, W, O, L.pLimit, L.pOffset, "DELETE");
- sqlite3DeleteFrom(pParse,X,W);
-}
-%endif
-%ifndef SQLITE_ENABLE_UPDATE_DELETE_LIMIT
-cmd ::= with(C) DELETE FROM fullname(X) indexed_opt(I) where_opt(W). {
- sqlite3WithPush(pParse, C, 1);
- sqlite3SrcListIndexedBy(pParse, X, );
+#else
+ if( O || L.pLimit ){
+sqlite3ErrorMsg(pParse, "%s on DELETE not supported", O?"ORDER
BY":"LIMIT");
+sqlite3ExprDelete(pParse->db, W);
+sqlite3ExprListDelete(pParse->db, O);
+sqlite3ExprDelete(pParse->db, L.pLimit);
+sqlite3ExprDelete(pParse->db, L.pOffset);
+W = 0;
+ }
+#endif
sqlite3DeleteFrom(pParse,X,W);
}
-%endif
%type where_opt {Expr*}
%destructor where_opt {sqlite3ExprDelete(pParse->db, $$);}
where_opt(A) ::= .{A = 0;}
where_opt(A) ::= WHERE expr(X). {A = X.pExpr;}
// The UPDATE command
//
-%ifdef SQLITE_ENABLE_UPDATE_DELETE_LIMIT
cmd ::= with(C) UPDATE orconf(R) fullname(X) indexed_opt(I) SET setlist(Y)
where_opt(W) orderby_opt(O) limit_opt(L). {
sqlite3WithPush(pParse, C, 1);
sqlite3SrcListIndexedBy(pParse, X, );
sqlite3ExprListCheckLength(pParse,Y,"set list");
+#if defined(SQLITE_ENABLE_UPDATE_DELETE_LIMIT) &&
!defined(SQLITE_OMIT_SUBQUERY)
W = sqlite3LimitWhere(pParse, X, W, O, L.pLimit, L.pOffset, "UPDATE");
- sqlite3Update(pParse,X,Y,W,R);
-}
-%endif
-%ifndef SQLITE_ENABLE_UPDATE_DELETE_LIMIT
-cmd ::= with(C) UPDATE orconf(R) fullname(X) indexed_opt(I) SET setlist(Y)
-where_opt(W). {
- sqlite3WithPush(pParse, C, 1);
- sqlite3SrcListIndexedBy(pParse, X, );
- sqlite3ExprListCheckLength(pParse,Y,"set list");
+#else
+ if( O || L.pLimit ){
+sqlite3ErrorMsg(pParse, "%s on UPDATE not supported", O?"ORDER
BY":"LIMIT");
+sqlite3ExprDelete(pParse->db, W);
+sqlite3ExprListDelete(pParse->db, O);
+sqlite3ExprDelete(pParse->db, L.pLimit);
+sqlite3ExprDelete(pParse->db, L.pOffset);
+W = 0;
+ }
+#endif
sqlite3Update(pParse,X,Y,W,R);
}
-%endif
%type setlist {ExprList*}
%destructor setlist {sqlite3ExprListDelete(pParse->db, $$);}
setlist(A) ::= setlist(Z) COMMA nm(X) EQ expr(Y). {
[sqlite] shell tool is no longer dynamically linked
2015-11-12 20:25 GMT+01:00 Lonnie Abelbeck:
> My current solution is to apply this build patch:
> And that seems to restore the previous behavior to dynamically link the
> sqlite3 shell tool.
Actually, Makefile.in is generated from Makefile.am, so the correct patch would
be as below in the SQLite sources. I noticed the same for the Cygwin build
(I'm Cygwin's SQLite package maintainer), and put the patch below in the
build system, so it will be applied with every new SQLite release. Problem
solved for me.
> It would be nice if like Fossil (--with-internal-sqlite), sqlite had a
> configure option to determine if the shell tool would be statically or
> dynamically linked, ex. --with-static-shell-tool
>
> I would expect sqlite would default to dynamically linked (if --enable-shared
> is passed), not sure why the change to static.
+1
If it would be configurable, that indeed would be best. Then it even
doesn't matter to me
what the default is.
My guess is the more distributions (e.g. Fedora, Ubuntu ) will
make (or have already
made) the same modification, since it's much easier to apply a patch than change
a distribution policy ;-)
Regards,
Jan Nijtmans
==
--- autoconf/Makefile.am
+++ autoconf/Makefile.am
@@ -4,16 +4,16 @@
lib_LTLIBRARIES = libsqlite3.la
libsqlite3_la_SOURCES = sqlite3.c
libsqlite3_la_LDFLAGS = -no-undefined -version-info 8:6:8
bin_PROGRAMS = sqlite3
-sqlite3_SOURCES = shell.c sqlite3.c sqlite3.h
-sqlite3_LDADD = @READLINE_LIBS@
-sqlite3_CFLAGS = $(AM_CFLAGS)
+sqlite3_SOURCES = shell.c
+sqlite3_LDADD = $(top_builddir)/libsqlite3.la @READLINE_LIBS@
+sqlite3_DEPENDENCIES = $(top_builddir)/libsqlite3.la
include_HEADERS = sqlite3.h sqlite3ext.h
EXTRA_DIST = sqlite3.1 tea
pkgconfigdir = ${libdir}/pkgconfig
pkgconfig_DATA = sqlite3.pc
man_MANS = sqlite3.1
[sqlite] Version 3.9.0 source_id mismatch
2015-10-15 18:18 GMT+02:00 Bruce Blackwell : > I do not know if it is significant or not, but this is the first time I > have ever seen this happen. > > sqlite3.dll from sqlite-dll-win32-x86-309.zip reports > sqlite_source_id() as 2015-10-14 18:30:13 > a43bb2b5cf9c7c19edbce37c883826eb0f7ed764 > However, the amalgamation files have #define SQLITE_SOURCE_ID "2015-10-14 > 12:29:53 a721fc0d89495518fe5612e2e3bbc60befd2e90d" The SOURCE_ID can be found in the SQLite fossil repository, in order to see exactly which sources the dll was compiled from. e.g. version 3.9.0 is here: <http://www.sqlite.org/src/info/a721fc0d89495518fe5612e2e3bbc60befd2e90d> The source-id from the compiled sqlite3.dll should be available in the same way: <http://www.sqlite.org/src/info/a43bb2b5cf9c7c19edbce37c883826eb0f7ed764> but it isn't. Most likely, the dll was compiled by cherry-picking [01d3ee7bbe4feeb8] (containing a dll symbol fix) to the 3.9.0 version. Most likely, this merge was committed to a local fossil repository (which created the alternative source_id), but never pushed back to the official repository. That's the best answer I can give. Regards, Jan Nijtmans
[sqlite] Form-Feed (0x0C) is not a space character in JSON
Hi all,
Just noted in the jsonIsSpace[] array: According to RFC 7159, JSON
only has 5 whitespace characters, FF (0x0C) is not among them:
ws = *(
%x20 / ; Space
%x09 / ; Horizontal tab
%x0A / ; Line feed or New line
%x0D; Carriage return
)
Suggested patch below.
Regards,
Jan Nijtmans
$ fossil diff
Index: ext/misc/json1.c
==
--- ext/misc/json1.c
+++ ext/misc/json1.c
@@ -50,11 +50,11 @@
** Growing our own isspace() routine this way is twice as fast as
** the library isspace() function, resulting in a 7% overall performance
** increase for the parser. (Ubuntu14.10 gcc 4.8.4 x64 with -Os).
*/
static const char jsonIsSpace[] = {
- 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 0, 1, 1, 0, 0,
+ 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 0, 0, 1, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
[sqlite] [sqlite-announce] SQLite version 3.9.0
2015-10-14 21:31 GMT+02:00 D. Richard Hipp: > Please report any problems to the sqlite-users at mailinglists.sqlite.org > mailing list, or directly to me. Thanks. Why does sqlite.h #include itself? <https://www.fossil-scm.org/index.html/artifact/f387eb7e7f85e11a?ln=7947> Although it doesn't actually create a problem, as far as I can tell. Sorry for not noticing this before. Regards, Jan Nijtmans
[sqlite] Proposed new version numbering scheme for SQLite - Feedback requested
2015-10-08 15:38 GMT+02:00 Richard Hipp : > Several users have proposed that SQLite adopt a new version numbering > scheme. The proposed change is currently uploaded on the "draft" > website: > > https://www.sqlite.org/draft/versionnumbers.html > https://www.sqlite.org/draft/releaselog/3_9_0.html > https://www.sqlite.org/draft/ > > If accepted, the new policy will cause the next release to be 3.9.0 > instead of 3.8.12. And the second number in the version will be > increased much more aggressively in future releases. > > Your feedback on the proposed policy change is appreciated. We will > delay the next release until there is a semblance of consensus on the > new policy. Reading the other reactions, there seems to be consensus on the next release being 3.9.0, not 3.8.12. So I hope the delay will not be that much. Details on the exact definition of X/Y/Z is not that important to me, but since you ask One idea could be to lower the number of 'major' releases to about twice a year. This means that Linux distributions, like Ubuntu and Fedora can know in advance which SQLite release will match their release. Ubuntu: <https://wiki.ubuntu.com/Releases> Fedora: <https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle> (everyone seems to think twice a year is optimal, don't know why) If there is a desire for new features to be released in between, this could be done by intermediate 9x releases, at will. e.g.: 3.9.0 - okt 2015 3.9.1 - nov 2015 (performance improvement/bugfix only) 3.9.90 - dec 2015 (well-tested, new feature 1 added + bugfixes) 3.9.2 - jan 2016 (bugfixes only, without feature 1) 3.9.91 - feb 2016 (well-tested, new feature 2 added + bugfixes) 3.10.0 - april 2016 (well-tested, contains feature 1 + 2 + more) 3.11.0 - okt 2016 3.79.0 - okt 2050 3.99.0 - okt 2060;-) Advantage: 1) less 'major' releases gives the signal to managers that apparently the software is more stable (even though we know that SQLite's trunk is very stable always). 2) No limitation when/what to release. It can be fully driven by the desire of SQLite consortium members: Whenever a new feature is implemented and ready to be released, it can always be done in an official 3.x.9y release, outside of the half-yearly schedule. 3) No need to adapt the tarball filename. 4) All 3.x.0 and 3.x.9y releases can be done directly from trunk, as done now. 3.x.[1-9]+ will generally be done from a branch. Disadvantage: 1) 3.x.9y releases will give the signal to managers being less stable than 3.x,y releases. We know that's not necessarily true, but that's the price for advantage 1) Just my 2c. Regards, Jan Nijtmans
[sqlite] json1.c: isalnum(), isspace(), and isdigit() usage
2015-08-26 19:03 GMT+02:00 Ralf Junker :
> ext/misc/json1.c uses the following functions from the C library:
>
> isalnum(): http://www.sqlite.org/src/artifact/541004e47235cefc?ln=564
> isspace(): http://www.sqlite.org/src/artifact/541004e47235cefc?ln=635
> isdigit(): http://www.sqlite.org/src/artifact/541004e47235cefc?ln=829
> Shouldn't json1.c avoid them for the same reasons?
Simpler is: cast the argument to (unsigned char), that
has the same effect (but is more efficient).
Proposed patch below.
Thanks!
Regards,
Jan Nijtmans
==
--- ext/misc/json1.c
+++ ext/misc/json1.c
@@ -583,18 +583,18 @@
char c;
u32 j;
int iThis;
int x;
JsonNode *pNode;
- while( isspace(pParse->zJson[i]) ){ i++; }
+ while( isspace((unsigned char)pParse->zJson[i]) ){ i++; }
if( (c = pParse->zJson[i])==0 ) return 0;
if( c=='{' ){
/* Parse object */
iThis = jsonParseAddNode(pParse, JSON_OBJECT, 0, 0);
if( iThis<0 ) return -1;
for(j=i+1;;j++){
- while( isspace(pParse->zJson[j]) ){ j++; }
+ while( isspace((unsigned char)pParse->zJson[j]) ){ j++; }
x = jsonParseValue(pParse, j);
if( x<0 ){
if( x==(-2) && pParse->nNode==(u32)iThis+1 ) return j+1;
return -1;
}
@@ -601,17 +601,17 @@
if( pParse->oom ) return -1;
pNode = >aNode[pParse->nNode-1];
if( pNode->eType!=JSON_STRING ) return -1;
pNode->jnFlags |= JNODE_LABEL;
j = x;
- while( isspace(pParse->zJson[j]) ){ j++; }
+ while( isspace((unsigned char)pParse->zJson[j]) ){ j++; }
if( pParse->zJson[j]!=':' ) return -1;
j++;
x = jsonParseValue(pParse, j);
if( x<0 ) return -1;
j = x;
- while( isspace(pParse->zJson[j]) ){ j++; }
+ while( isspace((unsigned char)pParse->zJson[j]) ){ j++; }
c = pParse->zJson[j];
if( c==',' ) continue;
if( c!='}' ) return -1;
break;
}
@@ -620,18 +620,18 @@
}else if( c=='[' ){
/* Parse array */
iThis = jsonParseAddNode(pParse, JSON_ARRAY, 0, 0);
if( iThis<0 ) return -1;
for(j=i+1;;j++){
- while( isspace(pParse->zJson[j]) ){ j++; }
+ while( isspace((unsigned char)pParse->zJson[j]) ){ j++; }
x = jsonParseValue(pParse, j);
if( x<0 ){
if( x==(-3) && pParse->nNode==(u32)iThis+1 ) return j+1;
return -1;
}
j = x;
- while( isspace(pParse->zJson[j]) ){ j++; }
+ while( isspace((unsigned char)pParse->zJson[j]) ){ j++; }
c = pParse->zJson[j];
if( c==',' ) continue;
if( c!=']' ) return -1;
break;
}
@@ -656,21 +656,21 @@
jsonParseAddNode(pParse, JSON_STRING, j+1-i, >zJson[i]);
if( !pParse->oom ) pParse->aNode[pParse->nNode-1].jnFlags = jnFlags;
return j+1;
}else if( c=='n'
&& strncmp(pParse->zJson+i,"null",4)==0
- && !isalnum(pParse->zJson[i+4]) ){
+ && !isalnum((unsigned char)pParse->zJson[i+4]) ){
jsonParseAddNode(pParse, JSON_NULL, 0, 0);
return i+4;
}else if( c=='t'
&& strncmp(pParse->zJson+i,"true",4)==0
- && !isalnum(pParse->zJson[i+4]) ){
+ && !isalnum((unsigned char)pParse->zJson[i+4]) ){
jsonParseAddNode(pParse, JSON_TRUE, 0, 0);
return i+4;
}else if( c=='f'
&& strncmp(pParse->zJson+i,"false",5)==0
- && !isalnum(pParse->zJson[i+5]) ){
+ && !isalnum((unsigned char)pParse->zJson[i+5]) ){
jsonParseAddNode(pParse, JSON_FALSE, 0, 0);
return i+5;
}else if( c=='-' || (c>='0' && c<='9') ){
/* Parse number */
u8 seenDP = 0;
@@ -729,11 +729,11 @@
if( zJson==0 ) return 1;
pParse->zJson = zJson;
i = jsonParseValue(pParse, 0);
if( pParse->oom ) i = -1;
if( i>0 ){
-while( isspace(zJson[i]) ) i++;
+while( isspace((unsigned char)zJson[i]) ) i++;
if( zJson[i] ) i = -1;
}
if( i<=0 ){
if( pCtx!=0 ){
if( pParse->oom ){
@@ -860,15 +860,15 @@
pRoot->jnFlags |= JNODE_APPEND;
pParse->aNode[iLabel].jnFlags |= JNODE_RAW;
}
return pNode;
}
- }else if( zPath[0]=='[' && isdigit(zPath[1]) ){
+ }else if( zPath[0]=='[' && isdigit((unsigned char)zPath[1]) ){
if( pRoot->eType!=JSON_ARRAY ) return 0;
i = 0;
zPath++;
-while( isdigit(zPath[0]) ){
+while( isdigit((unsigned char)zPath[0]) ){
i = i*10 + zPath[0] - '0';
zPath++;
}
if( zPath[0]!=']' ){
*pzErr = zPath;
[sqlite] Function lower on index expressions not allowed ?
2015-09-08 0:04 GMT+02:00 Richard Hipp : > My guess: You are using ICU or some other extension that is replacing > the built-in lower() function with another. And that extension is not > marking its new lower() function as SQLITE_DETERMINISTIC. > (https://www.sqlite.org/c3ref/c_deterministic.html) Just wondering, why doesn't ICU mark "upper" and "lower" as SQLITE_DETERMINISTIC ? <http://www.sqlite.org/src/artifact/b2732aef0b076e42?ln=461-469+482-483> Regards, Jan Nijtmans
[sqlite] SQLite3 to 64-bit DLL
2015-08-26 19:03 GMT+02:00 : > On my Win10, I'd like to compile SQLite3 to create a 64-bit DLL. The > intention is to use this DLL instead of the amalgamation, this way more than > one C++ application can access the same DLL. Please note that I am an > aficionado, not an expert when it comes to C++ and for SQL, well, this would > be my second attempt to get an application to use a database, as opposed to > flat files. > > How would you suggest I should proceed? is this even a good idea? If you like, you can download my build of the 64-bit dll, and the corresponding import files: <https://sourceforge.net/projects/cyqlite/files/3.8.11/> The sqlite-dll-win64-x64-3081101.zip file contains two import libraries you can use for your project: sqlite3.lib : Suitable for VC++ 6.0 or higher (up to the latest Visual Studio 2014) libsqlite3.dll.a : Suitable for any gcc version (mingw/mingw-64/msys/msys-2) The dll is suitable for any 64-bit windows environment. Regards, Jan Nijtmans
[sqlite] SQLite crash
Op 11 aug. 2015 17:06 schreef "Robert Weiss" het volgende: > > In the meantime I removed -DSQLITE_DEFAULT_WORKER_THREADS=4 from the compilation flags and the index was created successfully. Haste makes waste? > Thanks, everyone.Bob Weiss That explains it! Your build of sqlite starts win32 threads, which don't work well in a cygwin environment. On cygwin you should configure posix threads. I have a fix for that, it's included in the cygwin SQLite package. With that you can use multiple threads as you wish. Regards, Jan Nijtmans
[sqlite] SQLite crash
Op 7 aug. 2015 16:12 schreef "Robert Weiss" het volgende: > > I observed the sqlite command shell version 3.8.11.1 to crash (exit to the OSwithout an error message) while running in a Cygwin shell under Windows 7. Does the same crash occur when using cygwin's SQLite 3.8.10.2 package? In other words, is this a regression or a longstanding problem? Regards, Jan Nijtmans
[sqlite] Numerics bigger than 32-bit and sqlite as 64-bit TCL extension
2015-07-28 11:52 GMT-05:00 Richard Hipp :
> On 7/28/15, Rafa? Ponikwia wrote:
>> Hi,
>> I'm using sqlite3 TCL extension from Teapot (version 64-bit). When I try
>> to insert number bigger than signed 32-bit it inserts wrong number to
>> database.
>> % sqlite3 db C:/tmp/test.sqlite
>> % db eval {
CREATE TABLE test (num NUMERIC);
INSERT INTO test (num) VALUES ($l1), ($l2), ($l3);
SELECT * FROM test;
}
>> 2147483647 2147483649 -2147483647
>>
>
> I get the correct answer (2147483647 2147483649 2147483649) when I try
> this on 64-bit Ubuntu.
Tried this on both cygwin64 and mingw-w64 (64-bit), getting the same
correct answer in both environments. e.g.:
>tclsh86
% set tcl_platform(pointerSize)
8
% package require sqlite3
3.8.11.1
% info loaded
{C:/cygwin64/lib/sqlite3.8.11.1/sqlite38111.dll Sqlite3}
% set l1 [expr {2 ** 31 - 1}]
2147483647
% set l2 2147483649
2147483649
% set l3 [expr {$l1 + 2}]
2147483649
% sqlite3 db test.sqlite
% db eval {
CREATE TABLE test (num NUMERIC);
INSERT INTO test (num) VALUES ($l1), ($l2), ($l3);
SELECT * FROM test;
}
2147483647 2147483649 2147483649
%
@Andreas: could this be a compiler issue?
Regards,
Jan Nijtmans
[sqlite] SEGV in dbPrepareAndBind() in tclsqlite.c
2015-05-30 19:24 GMT+02:00 : > I think I've finally isolated the cause, but it appears to require Tcl > 8.6 plus Itcl plus Sqlite plus a specific naming of variables. My guess, reading through your story, is that this issue is really an issue in Itcl 4, not in sqlite. There have been a number of commits in Itcl recently which might fix this: <http://core.tcl.tk/itcl/timeline?y=ci> So, if you like, try out Itcl trunk and see if the same happens. It should be possible to construct a minimal example without sqlite, that would really prove that the issue is in Itcl. Depending the outcome, feel free to report this to the Itcl folks (which is not me ) Regards, Jan Nijtmans
[sqlite] Issue: Inconsistency of sqlite3_dbstat_register declaration
2015-05-11 16:33 GMT+02:00 Roger Binns : > On 05/11/2015 01:34 AM, Jan Nijtmans wrote: >> 2) If sqlite is not compiled with -DSQLITE_ENABLE_DBSTAT_VTAB=1, >> or the function is renamed (as it should) it wouldn't even work. > > That was my scenario. I just -DSQLITE_ENABLE_DBSTAT_VTAB and the code > didn't compile because of the inconsistency. Well, it's fixed now on trunk! Thanks, Richard! <http://www.sqlite.org/src/info/4e6520159e729b6e> Regards, Jan Nijtmans
[sqlite] Bug: Cannot compile the new sqlite-src-3081001: preprocessor and testuite errors
2015-05-11 10:01 GMT+02:00 Jan Stan?k : > 2) When I "fix" the previous error, I'm getting assertion failure > during the test suite run. ... > shell1-5.0...testfixture: > /builddir/build/BUILD/tcl8.6.3/generic/tclIO.c:5815: DoReadChars: > Assertion `!((statePtr)->flags & ((1<<9))) || ((statePtr)->flags & > ((1<<10))) || Tcl_InputBuffered((Tcl_Cha > nnel)chanPtr) == 0' failed. > > The testsuite error does not occur in the 3.9.* version. Did the Tcl version get an upgrade in the mean time? Does the problem still happen when running Tcl compiled from trunk? There was a regression introduced in recent Tcl 8.6.x versions, which will be fixed in (upcoming) version 8.6.5. So - in short - I suspect that this assertion is not SQLite's fault but Tcl's ;-). Regards, Jan Nijtmans
[sqlite] Issue: Inconsistency of sqlite3_dbstat_register declaration
2015-05-10 21:06 GMT+02:00 Roger Binns :
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> There is a forward declaration of sqlite3_dbstat_register (currently
> line 130871 in the 3.8.10.1 amalgamation):
>
> int sqlite3_dbstat_register(sqlite3*);
>
> Later is the actual implementation (currently line 155838 in the
> 3.8.10.1 amalgamation):
>
> SQLITE_API int SQLITE_STDCALL sqlite3_dbstat_register(sqlite3 *db){
>
> If SQLITE_API or SQLITE_STDCALL are set to anything then the
> inconsistency can cause a compiler error. In my case SQLITE_API is
> defined as static.
The function sqlite3_dbstat_register() shouln't be an exported function
at all, I would suggest to rename it to sqlite3DbstatInit, that would
be consistent with other compiled-in extensions (e.g. sqlite3RtreeInit)
and it would fix the problem you are describing.
Worse: the tcl extension uses sqlite3_dbstat_register() when compiled
with -DSQLITE_ENABLE_DBSTAT_VTAB=1, which means that
1) Initialization of the dbstat extension will be done twice.
2) If sqlite is not compiled with -DSQLITE_ENABLE_DBSTAT_VTAB=1, or
the function is renamed (as it should) it wouldn't even work.
The latter part is already fixed in the TEA version of SQLite.
Suggested patch:
<http://cyqlite.sourceforge.net/cgi-bin/sqlite/fdiff?v1=f2e740c1cc90060f=39dc9592b8f99cf9=1>
Regards,
Jan Nijtmans
[sqlite] Version 3.8.9 is in testing
2015-04-02 15:15 GMT+02:00 Richard Hipp :
> A draft of the 3.8.9 website is found at http://www.sqlite.org/draft/
> and in particular the change log can be seen at
> https://www.sqlite.org/draft/releaselog/3_8_9.html
I would have expected to find this change somewhere in the
release log:
<http://www.sqlite.org/src/info/6fc4e79a2350295a>
Regards,
Jan Nijtmans
Re: [sqlite] sqlite3 fails due to too long path (MAX_PATHNAME)
2015-02-02 11:59 GMT+01:00 Török Edwin <edwin+sqli...@etorok.net>: > Would it be possible to raise that limit, or output a better error message > that says why it failed to open the file? My suggestion would be to add something like this to sqliteLimit.h: /* ** Maximum supported path-length.. */ #ifndef SQLITE_MAX_PATH_LENGTH # define SQLITE_MAX_PATH_LENGTH 512 #endif and use that macro in os_unix.c in stead of the hardcoded '512' An amalgamation containing this (and an equivalent change in os_win.c) can be found here: http://cyqlite.sourceforge.net/cgi-bin/sqlite/tarball/cyqlite.tar.gz?uuid=trunk Hopefully, one day you will find this change (or something equivalent) in the official SQLite. Jan Nijtmans ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Compiling error on Cygwin on Windows 8.1: 3.8.7.4 and 3.8.8
2015-01-19 11:01 GMT+01:00 Frank Ho <frank...@263.net>: > I compiled the SQLite on the Cygwin 1.7.33 running on a Windows 8.1, here's > the error: > > .libs/sqlite3.o: In function `sqlite3ThreadProc': > ../sqlite-autoconf-3080800/sqlite3.c:22471: undefined reference to > `_endthreadex' > .libs/sqlite3.o: In function `sqlite3ThreadCreate': > ../sqlite-autoconf-3080800/sqlite3.c:22493: undefined reference to > `_beginthreadex' > collect2: error: ld returned 1 exit status The problem is here: <http://www.sqlite.org/src/artifact/779d588e3b7756ec?ln=44-50> For Cywin, SQLITE_MUTEX_PTHREADS should be set to 1, but in those lines SQLITE_MUTEX_W32 is set in stead. There was a commit which was Any chance this will be fixed for SQLite 3.8.9? There was a commit in SQLite which simply disables all multi-threading for Cygwin: that's indeed another possible 'solution' ;-) Regards, Jan Nijtmans ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Compiling error on Cygwin on Windows 8.1: 3.8.7.4 and 3.8.8
2015-01-19 11:01 GMT+01:00 Frank Ho <frank...@263.net>: > Hi, > > I compiled the SQLite on the Cygwin 1.7.33 running on a Windows 8.1, here's > the error: > > .libs/sqlite3.o: In function `sqlite3ThreadProc': > ../sqlite-autoconf-3080800/sqlite3.c:22471: undefined reference to > `_endthreadex' > .libs/sqlite3.o: In function `sqlite3ThreadCreate': > ../sqlite-autoconf-3080800/sqlite3.c:22493: undefined reference to > `_beginthreadex' > collect2: error: ld returned 1 exit status If you are interested, you can get a corrected amalgamation here: <http://cyqlite.sourceforge.net/cgi-bin/sqlite/raw/generic/sqlite3.c?name=83a26f4777390dbcfcc58ba146354002ca2de0c8> An official cygwin build of SQLite 3.8.8 will be available soon. Regards, Jan Nijtmans ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] default ignore-glob for sqlite
2014-11-21 1:23 GMT+01:00 E. Timothy Uy: > Jan, I added to your list > > .target_source > lemon.obj > libsqlite3.lib > mkkeywordhash.obj > sqlite3.def > sqlite3.dll > sqlite3.exp > sqlite3.lib Thanks! I added them too. My preferred win32/64 compilation environment is MinGW(-w64), therefore I generally don't need those ;-) Regards, Jan Nijtmans ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] default ignore-glob for sqlite
2014-11-06 1:14 GMT+01:00 E. Timothy Uy <t...@loqu8.com>: > Hi, I noticed that the ignore-glob for sqlite is empty. Is it just because > fossil does not transfer this information? What should I be using? I'm using the "ignore-glob" versioned setting below. Regards, Jan Nijtmans $ cat .fossil-settings/ignore-glob tsrc/* *.db Makefile config.h config.log config.status keywordhash.h lemon lemon.exe lempar.c libsqlite3.la libtclsqlite3.la libtool mkkeywordhash mkkeywordhash.exe opcodes.c opcodes.h parse.c parse.h parse.h.temp parse.out parse.y shell.c sqlite3 sqlite3.c sqlite3.exe sqlite3.h sqlite3.lo sqlite3.o sqlite3.pc sqlite3ext.h tclsqlite.lo tclsqlite.o testfixture testfixture.exe ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] HELP sqlite3 used in vxworks has someproblem？
2014-09-01 13:04 GMT+02:00 Andy Ling <andy.l...@quantel.com>: > Although this doesn't feel right having to keep extending the list of error > codes that are checked. > I'm not sure what else can be done though. Maybe some compile options that > let you choose. Here is a list of possible error-codes I found: <http://www.vxdev.com/docs/vx55man/vxworks/errno/errnoNumList.html> The value 13 is listed here as EACCES, I really doubt this one should be added: If there really is an access problem, I think that shouldn't be masked. There are two entries that end with _FILE_NOT_FOUND, the other one is: 1310723 0x140003 S_rt11FsLib_FILE_NOT_FOUND This suggests that for VxWorks an additional check for 0x140003 might work if you use the rt11 filesystem (whatever that is .) Other possible candidates: 2686989 0x29000d S_netDrv_NO_SUCH_FILE_OR_DIR 2949130 0x2d000a S_nfsDrv_NO_SUCH_FILE_OR_DIR 7602186 0x74000a S_cdromFsLib_NO_SUCH_FILE_OR_DIRECTORY The list is not so long, if it helps then it is doable to just add them all. But feedback on behavior on different file systems is crucial, I wouldn't just add all of them blindly. Regards, Jan Nijtmans ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Win32 .def exports != documented APIs ?
2014-08-29 16:22 GMT+02:00 Jan Nijtmans <jan.nijtm...@gmail.com>: > I doubt the usefulness > of sqlite3_win32_is_nt(), because on current supported > systems this function should return 1 anyway. On > Windows RT it returns - surprisingly - 0 (which is > already fixed on trunk), so this function cannot > be thrusted anyway. ;-) Small correction: the fix I mentioned is in the "winrt" branch, it's not merged to trunk yet: <http://www.sqlite.org/src/timeline?r=winrt=3> Regards, Jan Nijtmans ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Win32 .def exports != documented APIs ?
2014-08-29 5:22 GMT+02:00 Howard Kapustein <howard.kapust...@microsoft.com>: > The Win32 DLL download includes a .def file, but comparing the exports with > the documentation's function page shows several inconsistencies > > > > doc but not .def > > * sqlite3_mutex_held > * sqlite3_mutex_notheld According to the documentation: > The SQLite core only > provides implementations for these routines when it is compiled > with the SQLITE_DEBUG flag. > * sqlite3_unlock_notify This function is only available when compiled with -DSQLITE_ENABLE_UNLOCK_NOTIFY So that's correct as well. > * sqlite3_version (not a real API just a page name for the various > version functions/global so ignore) Windows DLL's have some problem with exported data, and there is a function sqlite3_libversion_number() which does the same. > sqlite3_rtree_geometry_callback > sqlite3_rtree_query_callback > > sqlite3_win32_is_nt Those 3 are new in SQLite 3.8.6. I doubt the usefulness of sqlite3_win32_is_nt(), because on current supported systems this function should return 1 anyway. On Windows RT it returns - surprisingly - 0 (which is already fixed on trunk), so this function cannot be thrusted anyway. ;-) > sqlite3_win32_mbcs_to_utf8 > sqlite3_win32_set_directory > sqlite3_win32_sleep > sqlite3_win32_utf8_to_mbcs > sqlite3_win32_write_debug Those are all win32-specific. The only function that might be interesting on some embedded environments (read: Windows CE) is sqlite3_win32_set_directory(). The other four are not portable anyway, I don't see any practical use for them. Regards, Jan Nijtmans ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Crash in sqlite3_mutex_try [Was: SQLite 3.8.6 beta]
2014-08-22 9:14 GMT+02:00 Jan Nijtmans <jan.nijtm...@gmail.com>: > It looks like this is on its way to being corrected: > > > However, I don't think this will work on Win95/98/NT Fixed here: <http://www.sqlite.org/src/info/9fe0f0754c> Thanks! No more remarks! Regards, Jan Nijtmans ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Crash in sqlite3_mutex_try [Was: SQLite 3.8.6 beta]
2014-08-15 12:50 GMT+02:00 Jan Nijtmans <jan.nijtm...@gmail.com>:
> Looking at the function sqlite3_win32_is_nt()
> It should simply return 1 on any
> currently supported platform. Looking closely,
> it returns 0 on Windows RT, but who cares
> (leaving the "why" as practice for the reader)
It looks like this is on its way to being corrected:
However, I don't think this will work on Win95/98/NT
(not that I really care ..). The reason: GetVersionExW()
will be called to check whether the kernal is NT-based,
but Win95/98/NT is not NT-based so it doesn't have
this function ;-). Suggested solution:
<http://www.sqlite.org/src/info/169fc47e16>
Second-best suggested solution as patch below
(based on the winrt branch)
Regards,
Jan Nijtmans
Index: src/os_win.c
==
--- src/os_win.c
+++ src/os_win.c
@@ -1323,17 +1323,17 @@
** kernel.
*/
return 1;
#elif defined(SQLITE_WIN32_GETVERSIONEX) && SQLITE_WIN32_GETVERSIONEX
if( osInterlockedCompareExchange(_os_type, 0, 0)==0 ){
-#if defined(SQLITE_WIN32_HAS_WIDE)
+#if !defined(SQLITE_WIN32_HAS_ANSI)
OSVERSIONINFOW sInfo;
sInfo.dwOSVersionInfoSize = sizeof(sInfo);
osGetVersionExW();
osInterlockedCompareExchange(_os_type,
(sInfo.dwPlatformId == VER_PLATFORM_WIN32_NT) ? 2 : 1, 0);
-#elif defined(SQLITE_WIN32_HAS_ANSI)
+#else
OSVERSIONINFOA sInfo;
sInfo.dwOSVersionInfoSize = sizeof(sInfo);
osGetVersionExA();
osInterlockedCompareExchange(_os_type,
(sInfo.dwPlatformId == VER_PLATFORM_WIN32_NT) ? 2 : 1, 0);
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Crash in sqlite3_mutex_try [Was: SQLite 3.8.6 beta]
2014-08-12 10:35 GMT+02:00 Jan Nijtmans <jan.nijtm...@gmail.com>: > > $ i686-w64-mingw32-gcc -c -DSQLITE_WIN32_NO_ANSI sqlite3.c > sqlite3.c: In function ‘sqlite3_win32_is_nt’: > sqlite3.c:33312:10: error: ‘sInfo’ undeclared (first use in this function) > > (sInfo.dwPlatformId == VER_PLATFORM_WIN32_NT) ? 2 : 1, 0); > ^ > sqlite3.c:33312:10: note: each undeclared identifier is reported only once > for each function it appears in > Fixed here: <http://www.sqlite.org/src/info/6715991296> Thanks! Looking at the function sqlite3_win32_is_nt(): <http://www.sqlite.org/src/artifact/1c936c7b06?ln=1321-1337> it's getting more and more complicated, without doing really anything: It should simply return 1 on any currently supported platform. Looking closely, it returns 0 on Windows RT, but who cares (leaving the "why" as practice for the reader) Best overall-solution can be found here: <http://www.sqlite.org/src/info/169fc47e16> A big +1 from me for this, paying any attention to Win95 just isn't worth the effort IMHO! Regards, Jan Nijtmans ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] HELP sqlite3 used in vxworks has someproblem？
2014-08-13 14:31 GMT+02:00 Andy Ling <andy.l...@quantel.com>: > > From: drhsql...@gmail.com [mailto:drhsql...@gmail.com] On Behalf Of > Richard Hipp > > OK, I did find some cases where unlink() is called on files that do not > exist. > > > Anyway, a patch has now been checked in. > > Great, thank Congratulations to Andy and Richard for getting VxWorks support back into SQLite. Just one more question: What is the status of the Makefile.vxworks file in the SQLite source code? Especially line 68 puzzles me, what is SQLITE_ENABLE_LOCKING_STYLE=1 needed for? (User "chw", whoever that is, should be able to answer that question, since he/she committed this Makefile.vxworks) <http://www.sqlite.org/src/artifact/034289efa9?ln=68> Regards, Jan Nijtmans ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] HELP sqlite3 used in vxworks has someproblem？
2014-08-12 15:27 GMT+02:00 Richard Hipp <d...@sqlite.org>: > But we cannot use Jan's changes directly because he lives in a jurisdiction > that does not recognize the ability of an author to contribute their work > into the public domain. We can only use Jan's changes as a guideline for > implementing our own changes. > At least that's what the famous Lawyer Lawrence Rosen believes. For another opinion, see: <http://cr.yp.to/publicdomain.html> Unfortunately, I'm not a lawyer :-( Regards, Jan Nijtmans ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] HELP sqlite3 used in vxworks has someproblem？
2014-08-12 14:26 GMT+02:00 Richard Hipp <d...@sqlite.org>: > This is very awkward working through a proxy. If Mr. Ling (or anybody else > with access to a VxWorks development system) wants VxWorks support in > SQLite, he can come to this mailing list himself and submit suggestions > here, where we can ask questions. No more VxWorks changes without direct > communication with actual VxWorks developers. > Original discussion can be found here: <http://www.mail-archive.com/sqlite-users@sqlite.org/msg84480.html> Regards, Jan Nijtmans ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] HELP sqlite3 used in vxworks has someproblem？
2014-08-03 9:56 GMT+02:00 Jan Nijtmans <jan.nijtm...@gmail.com>: > 2014-08-02 16:00 GMT+02:00 王庆刚 <2004wqg2...@163.com>: > > hi ， Can Sqlite3.c and sqlite.h be compiled in Workbench3.2 for > Vxworks6.8 ? > > When I compile them , there have so many problems . > > You can find the necessary changes here: > < > http://fossil-scm.org/index.html/vpatch?from=dd5743a8239d1ce9=b68f65bb69a098a1 > > > thanks to Andy Ling. > > Still has to be reviewed by the SQLite developers for inclusion in 3.8.6 > (not tested yet on other platforms than vxworks, win32/64 and Linux, > there it works fine) > New attempt here, base on current SQLite trunk: <http://fossil-scm.org/index.html/info/c2d4bd7365> Regards, Jan Nijtmans ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Crash in sqlite3_mutex_try [Was: SQLite 3.8.6 beta]
2014-08-11 13:12 GMT+02:00 Jan Nijtmans <jan.nijtm...@gmail.com>: > And below is a minimal patch which fixes this problem. > Unfortunately, latest SQLite trunk, which fixes the SQLITE_WIN32_GETVERSIONEX problem brought back the SQLITE_WIN32_NO_ANSI problem I reported earlier -( $ i686-w64-mingw32-gcc -c -DSQLITE_WIN32_NO_ANSI sqlite3.c sqlite3.c: In function ‘sqlite3_win32_is_nt’: sqlite3.c:33312:10: error: ‘sInfo’ undeclared (first use in this function) (sInfo.dwPlatformId == VER_PLATFORM_WIN32_NT) ? 2 : 1, 0); ^ sqlite3.c:33312:10: note: each undeclared identifier is reported only once for each function it appears in I could deliver a patch, but there are two fundementally different (but both correct) approaches to handle this. Regards, Jan Nijtmans ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] Crash in sqlite3_mutex_try [Was: SQLite 3.8.6 beta]
2014-08-08 23:34 GMT+02:00 Richard Hipp>:
> Please continue to test the latest snapshots and report any issues you find.
I already reported this to sqlite-dev, but without test-case exposing the
problem. Here is the test-case, which is 100% reproducable.
And below is a minimal patch which fixes this problem.
=== main.c
#include
int main(){
sqlite3_mutex *mutex = sqlite3_mutex_alloc(SQLITE_MUTEX_RECURSIVE);
int rc = sqlite3_mutex_try(mutex);
if( rc == SQLITE_OK) sqlite3_mutex_leave(mutex);
}
==
Compile this using any Windows compiler (MSVC, MinGW, MinGW-w64)
with the following options.e.g.:
i686-w64-mingw32-gcc -o bug.exe -DNTDDI_VERSION=NTDDI_WINBLUE
-D_WIN32_WINNT=0x0400 -DSQLITE_THREADSAFE=1 main.c sqlite3.c
Then simply run "bug.exe", it will crash immediately in the function
sqlite3_win32_is_nt(), because osGetVersionExW is a NULL pointer.
Regards,
Jan Nijtmans
-- Forwarded message ------
From: Jan Nijtmans <jan.nijtm...@gmail.com>
Date: 2014-08-05 13:24 GMT+02:00
Subject: Re: SQLite trunk on win32 broken with -DSQLITE_WIN32_NO_ANSI
To: sqlite-dev <sqlite-...@sqlite.org>
2014-08-03 9:37 GMT+02:00 Jan Nijtmans <jan.nijtm...@gmail.com>:
> Fixed here:
> <http://www.sqlite.org/src/info/ba78265429>
>
> Thanks!
Actually, just discovered that it is still not fixed for
all cases: When SQLITE_WIN32_GETVERSIONEX
is equal to 0 (later MS SDK's), then any call to
sqlite3_win32_is_nt() will crash because the
function osGetVersionExW() is a null pointer ;-(
Suggested patch (current SQLite trunk) below.
Regards,
Jan Nijtmans
Index: src/os_win.c
==
--- src/os_win.c
+++ src/os_win.c
@@ -413,11 +413,11 @@
** In order to facilitate testing on a WinNT system, the test fixture
** can manually set this value to 1 to emulate Win98 behavior.
*/
#ifdef SQLITE_TEST
LONG volatile sqlite3_os_type = 0;
-#else
+#elif SQLITE_WIN32_GETVERSIONEX
static LONG volatile sqlite3_os_type = 0;
#endif
#ifndef SYSCALL
# define SYSCALL sqlite3_syscall_ptr
@@ -1308,10 +1308,11 @@
/*
** This function determines if the machine is running a version of Windows
** based on the NT kernel.
*/
int sqlite3_win32_is_nt(void){
+#if SQLITE_WIN32_GETVERSIONEX
if( osInterlockedCompareExchange(_os_type, 0, 0)==0 ){
#if defined(NTDDI_VERSION) && NTDDI_VERSION >= NTDDI_WIN8
OSVERSIONINFOW sInfo;
sInfo.dwOSVersionInfoSize = sizeof(sInfo);
osGetVersionExW();
@@ -1322,10 +1323,13 @@
#endif
osInterlockedCompareExchange(_os_type,
(sInfo.dwPlatformId == VER_PLATFORM_WIN32_NT) ? 2 : 1, 0);
}
return osInterlockedCompareExchange(_os_type, 2, 2)==2;
+#else
+ return 1;
+#endif
}
#ifdef SQLITE_WIN32_MALLOC
/*
** Allocate nBytes of memory.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] HELP sqlite3 used in vxworks has someproblem？
2014-08-02 16:00 GMT+02:00 王庆刚 <2004wqg2...@163.com>: > hi ， Can Sqlite3.c and sqlite.h be compiled in Workbench3.2 for > Vxworks6.8 ? > When I compile them , there have so many problems . > ___ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users You can find the necessary changes here: <http://fossil-scm.org/index.html/vpatch?from=dd5743a8239d1ce9=b68f65bb69a098a1> thanks to Andy Ling. Still has to be reviewed by the SQLite developers for inclusion in 3.8.6 (not tested yet on other platforms than vxworks, win32/64 and Linux, there it works fine) Regards, Jan Nijtmans ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] ISO time leap second.
2014-07-28 18:28 GMT+02:00 Igor Tandetnik <i...@tandetnik.org>:
> What do you mean "ignore"? Can you specify precisely what the semantics of
> such a timestamp should be, in all the date/time manipulation operations
> SQLite supports?
Just as julianday('2012-06-30T24:00:00') is exactly equal to
julianday('2012-07-01T00:00:00'), my proposal is that
julianday('2012-06-30T23:59:60') is handled as being
equal to this exact same timestamp. That's easiest to
implement changing only 2 bytes to SQLite's source code.
OK, OK, the documentation at <http://www.sqlite.org/lang_datefunc.html>
should be updated to, but that's just a single change 59 -> 60
B.T.W., try "man strftime" on Ubuntu:
> %S The second as a decimal number (range 00 to 60). (The range is
> up to 60 to allow for occasional leap seconds.)
It looks like the POSIX strftime() function is already
adapted to handle this 'problem' exactly the same way.
Regards,
Jan Nijtmans
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] ISO time leap second.
2014-07-28 17:10 GMT+02:00 Igor Tandetnik <i...@tandetnik.org>: > All your fix does is have the parser accept "60" as valid seconds field. > That's not very interesting. Yes, that's exactly all that I'm after. ISO 8601 does not specify how leap seconds are handled, it just specified which date-stamps are valid and which not. It's perfectly OK for fossil/SQLite to ignore the leap second, it's not OK that an error-message is produced for a valid ISO 8601 time-stamp. ISO specifies that seconds must be between 0 and 60, not between 0 and 59, just as hours can be between 0 and 24, not between 0 and 23 (which SQLite's parser adheres to) <http://en.wikipedia.org/wiki/ISO_8601> >ISO 8601 uses the 24-hour clock system. The basic format is [hh][mm][ss] > and the extended format is [hh]:[mm]:[ss]. > >[hh] refers to a zero-padded hour between 00 and 24 (where 24 is only used > to denote midnight at the end of a calendar day). >[mm] refers to a zero-padded minute between 00 and 59. >[ss] refers to a zero-padded second between 00 and 60 (where 60 is only > used to denote an added leap second). That's not what SQLite implements (although it is very close) Regards, Jan Nijtmans ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] ISO time leap second.
2014-07-28 16:53 GMT+02:00 Richard Hipp <d...@sqlite.org>: > Better to keep the code simpler and just say that SQLite (and hence Fossil) > does not know about leap seconds. If you can do that in two bytes ;-) Regards, Jan Nijtmans ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] ISO time leap second.
According to <http://en.wikipedia.org/wiki/Leap_second>, the
following should be perfectly valid:
$ fossil new --date-override 2012-06-30T23:59:60 foo.fossil
unrecognized date format (2012-06-30T23:59:60): use "-MM-DD HH:MM:SS.SSS"
Suggested patch to fossil (and SQLite trunk, with adapted test-case):
Regards,
Jan Nijtmans
Index: src/sqlite3.c
==
--- src/sqlite3.c
+++ src/sqlite3.c
@@ -14769,11 +14769,11 @@
return 1;
}
zDate += 5;
if( *zDate==':' ){
zDate++;
-if( getDigits(zDate, 2, 0, 59, 0, )!=1 ){
+if( getDigits(zDate, 2, 0, 60, 0, )!=1 ){
return 1;
}
zDate += 2;
if( *zDate=='.' && sqlite3Isdigit(zDate[1]) ){
double rScale = 1.0;
Index: src/date.c
==
--- src/date.c
+++ src/date.c
@@ -175,11 +175,11 @@
return 1;
}
zDate += 5;
if( *zDate==':' ){
zDate++;
-if( getDigits(zDate, 2, 0, 59, 0, )!=1 ){
+if( getDigits(zDate, 2, 0, 60, 0, )!=1 ){
return 1;
}
zDate += 2;
if( *zDate=='.' && sqlite3Isdigit(zDate[1]) ){
double rScale = 1.0;
Index: test/date.test
==
--- test/date.test
+++ test/date.test
@@ -64,13 +64,14 @@
datetest 1.23 julianday(12345.6) 12345.6
datetest 1.23b julianday('12345.6') 12345.6
datetest 1.24 {julianday('2001-01-01 12:00:00 bogus')} NULL
datetest 1.25 {julianday('2001-01-01 bogus')} NULL
datetest 1.26 {julianday('2001-01-01 12:60:00')} NULL
-datetest 1.27 {julianday('2001-01-01 12:59:60')} NULL
+datetest 1.27 {julianday('2001-01-01 12:59:61')} NULL
datetest 1.28 {julianday('2001-00-01')} NULL
datetest 1.29 {julianday('2001-01-00')} NULL
+datetest 1.30 {julianday('2001-01-01 12:59:60')} 2451911.0417
datetest 2.1 datetime(0,'unixepoch') {1970-01-01 00:00:00}
datetest 2.1b datetime(0,'unixepoc') NULL
datetest 2.1c datetime(0,'unixepochx') NULL
datetest 2.1d datetime('2003-10-22','unixepoch') NULL
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Entry Points missing from sqlite3ext.h
2014-07-22 0:13 GMT+02:00 Peter Aronson <pbaron...@att.net>: > Found in 3.8.4.3. Missing from sqlite3ext.h are sqlite3_auto_extension() and > sqlite3_cancel_auto_extension(). > > Now, you might ask, why would I need these functions in an extension? Well, > it turns out I'm writing a virtual table that accesses someone else's library > that also uses SQLite, at least some of the time, and I don't want my > extension being run on that library's SQLite connection. At best it's a > waste of time, and at worst it could confuse the other library. So I call > sqlite3_cancel_auto_extension() to cancel my extension before calling the > other library's open function (which might open SQLite), and afterwards I set > it again using sqlite3_auto_extension(). Sounds reasonable to me. Suggested patch below. Regards, Jan Nijtmans Index: src/loadext.c == --- src/loadext.c +++ src/loadext.c @@ -388,11 +388,16 @@ sqlite3_stricmp, sqlite3_uri_boolean, sqlite3_uri_int64, sqlite3_uri_parameter, sqlite3_vsnprintf, - sqlite3_wal_checkpoint_v2 + sqlite3_wal_checkpoint_v2, + /* + ** Added for 3.8.6 + */ + sqlite3_auto_extension, + sqlite3_cancel_auto_extension }; /* ** Attempt to load an SQLite extension library contained in the file ** zFile. The entry point is zProc. zProc may be 0 in which case a Index: src/sqlite3ext.h == --- src/sqlite3ext.h +++ src/sqlite3ext.h @@ -248,10 +248,13 @@ int (*uri_boolean)(const char*,const char*,int); sqlite3_int64 (*uri_int64)(const char*,const char*,sqlite3_int64); const char *(*uri_parameter)(const char*,const char*); char *(*vsnprintf)(int,char*,const char*,va_list); int (*wal_checkpoint_v2)(sqlite3*,const char*,int,int*,int*); + /* Version 3.8.6 and later */ + int (*auto_extension)(void (*xInit)(void)); + int (*cancel_auto_extension)(void (*xInit)(void)); }; /* ** The following macros redefine the API routines so that they are ** redirected throught the global sqlite3_api structure. @@ -465,10 +468,12 @@ #define sqlite3_uri_booleansqlite3_api->uri_boolean #define sqlite3_uri_int64 sqlite3_api->uri_int64 #define sqlite3_uri_parameter sqlite3_api->uri_parameter #define sqlite3_uri_vsnprintf sqlite3_api->vsnprintf #define sqlite3_wal_checkpoint_v2 sqlite3_api->wal_checkpoint_v2 +#define sqlite3_auto_extension sqlite3_api->auto_extension +#define sqlite3_cancel_auto_extension sqlite3_api->cancel_auto_extension #endif /* SQLITE_CORE */ #ifndef SQLITE_CORE /* This case when the file really is being compiled as a loadable ** extension */ ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] trying to get things to work from the command line on windows 7 x64
2014-07-11 13:45 GMT+02:00 Jonathan Leslie <jlesli...@yahoo.com>: > Jan, > > Yes, thank you I see. the download of the x64 mingw is failing behind my > proxy here. the > installer wants to phone home for some repository tool. is there anyway > around that? Yes, there is a way around that. Yesterday, you wrote: 2014-07-10 22:36 GMT+02:00 Jonathan Leslie <jlesli...@yahoo.com>: > Update: ok this is working in cygwin, so maybe my GCC compiler on the > windows side cmd.exe side is all higgly piggly? If you have Cygwin already, just install Cygwin's "mingw64-x86_64-gcc-core" package. In stead of "gcc" you need to use "x86_64-w64-mingw32-gcc" (and the same for various other tools like "dlltool" and "ld"). This way, you create a fully functional 64-bit environment which works with the 64-bit SQLite dll (and runs outside of Cygwin as well). > OR.... > > can I use the 32-bit sqlite? That's another possibility. Regards, Jan Nijtmans ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] trying to get things to work from the command line on windows 7 x64
2014-07-10 22:17 GMT+02:00 Jonathan Leslie <jlesli...@yahoo.com>: > question 1) what am I doing wrong? Your compiler is 32-bit MinGW, but you unpacked the 64-bit dll in your current directory. Regards, Jan Nijtmans ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] affinity critical problem with 3.8.5 - IN single value optimisation
2014-07-08 16:35 GMT+02:00 Hinrichsen, John <jhinrich...@c10p.com>: > This is a nasty bug; I do not see any follow-up regarding a fix. <http://www.sqlite.org/src/info/92f7ad43db> <http://www.sqlite.org/src/info/9a8b09f8e6> Regards, Jan Nijtmans ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Building for vxWorks
2014-07-07 14:44 GMT+02:00 Andy Ling <andy.l...@quantel.com>:
> Removing the SQLITE_ENABLE_LOCKING_STYLE I get
...
> sqlite3.c: In function 'fileHasMoved':
> sqlite3.c:25236: error: 'struct unixFileId' has no member named 'ino'
> sqlite3.c: In function 'semCheckReservedLock':
...
> sqlite3.c:26372: warning: unused variable 'statBuf'
> sqlite3.c: In function 'semLock':
...
> sqlite3.c:26425: warning: unused variable 'fd'
Below my suggested patch (derived from todays trunk)
which should solve the above 2 warnings and the
error. All other warnings/errors seems
to derive from the missing and maybe
other header files ( ???)
I don't have VxWorks, just tested this on Linux using
-DOS_VXWORKS=1, as suggested here:
Apparently the function fileHasMoved (new in SQLite 3.8.3)
was never tested on VxWorks, otherwise it would have been
discovered that 'struct unixFileId' has different fields on VxWorks
compared to other UNIX platforms.
I hope this brings it a little bit closer to fully working on VxWorks.
Regards,
Jan Nijtmans
Index: src/os_unix.c
==
--- src/os_unix.c
+++ src/os_unix.c
@@ -1301,13 +1301,19 @@
/*
** Return TRUE if pFile has been renamed or unlinked since it was first opened.
*/
static int fileHasMoved(unixFile *pFile){
+#if OS_VXWORKS
+ return pFile->pInode!=0 &&
+ (pFile->pId!=pFile->pInode->fileId.pId);
+
+#else
struct stat buf;
return pFile->pInode!=0 &&
(osStat(pFile->zPath, )!=0 ||
buf.st_ino!=pFile->pInode->fileId.ino);
+#endif
}
/*
** Check a unixFile that is a database. Verify the following:
@@ -2446,11 +2452,10 @@
}
/* Otherwise see if some other process holds it. */
if( !reserved ){
sem_t *pSem = pFile->pInode->pSem;
-struct stat statBuf;
if( sem_trywait(pSem)==-1 ){
int tErrno = errno;
if( EAGAIN != tErrno ){
rc = sqliteErrorFromPosixError(tErrno, SQLITE_IOERR_CHECKRESERVEDLOCK);
@@ -2499,11 +2504,10 @@
** This routine will only increase a lock. Use the sqlite3OsUnlock()
** routine to lower a locking level.
*/
static int semLock(sqlite3_file *id, int eFileLock) {
unixFile *pFile = (unixFile*)id;
- int fd;
sem_t *pSem = pFile->pInode->pSem;
int rc = SQLITE_OK;
/* if we already have a lock, it is exclusive.
** Just adjust level and punt on outta here. */
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Building for vxWorks
2014-07-04 11:52 GMT+02:00 Andy Ling <andy.l...@quantel.com>: > I now have sqlite running under vxWorks. As nobody offered any suggestions, I > thought I would share my experience in the hope it will help others and maybe > feed some changes back into the main code. > semaphone.h is included if SQLITE_ENABLE_LOCKING_STYLE is defined, but I > couldn't get it to build with that set. The first logical question is: Why you couldn't get it to build with that set? What exact error-message did you get? I think that's the first thing that should be fixed before trying other refinements. Regards, Jan Nijtmans ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] 64-bit precompiled command-line shell binary
2014-07-01 21:12 GMT+02:00 RSmith <rsm...@rsweb.co.za>: > I seem to remember a similar question having surfaced some time ago but > cannot find the reference now - so let me ask the great forum devs again: > WIll the 64-bit version of sqlite3.exe be able to use >2GB of memory for > itself Really don't know, but I guess the answer should be: Yes. Just try it, I'm interested in your feed-back. > is this different to the 32bit version, and if so, does anyone have > a pre-compiled 64bit sqlite3.exe version please? There is now, you can download it here: <http://sourceforge.net/projects/cyqlite/files/3.8.5/sqlite-shell-win64-x64-3080500.zip/download> sqlite3.exe is (cross-)compiled using the MinGW-w64 compiler as follows: x86_64-w64-mingw32-gcc -o sqlite3.exe -DUSE_SYSTEM_SQLITE=1 shell.c sqlite3.dll x86_64-w64-mingw32-strip -o sqlite3.exe This means that it's only a small .exe (64 kB) which uses a (64-bit, 547 kB) "sqlite3.dll" residing in the same directory to do the real work. You can replace sqlite3.dll with any other (64-bit) version, if it works then the dll is compatible with the SQLite 3.8.5 shell, if it doesn't work then there is some incompatibility (no guarantees, but it works with the 64-bit sqlite3.dll download provided by <http://wwwsqlite.org/download.html> as well). Regards, Jan Nijtmans ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] [ANNOUNCEMENT] Updated: fossil 20140612172556-1 -- DVCS with built-in wiki, http server and issue tracker
2014-06-13 16:09 GMT+02:00 Jari Aalto: >> CYGWIN INSTALLATION INFORMATION > === > If you have questions or comments, please send them to the Cygwin > mailing list at <cygwin(at)cygwin.com>. I tried the new fossil binary for Cygwin, and got the following: $ fossil sqlite cygwin warning: MS-DOS style path detected: C:/fossil/fossil.fossil Preferred POSIX equivalent is: /cygdrive/c/fossil/fossil.fossil CYGWIN environment variable option "nodosfilewarning" turns off this warning. Consult the user's guide for more details about POSIX paths: http://cygwin.com/cygwin-ug-net/using.html#using-pathnames SQLite version 3.8.5 2014-06-04 14:06:34 Enter ".help" for usage hints. sqlite> .databases seq name file --- --- -- 0main C:\fossil\fossil.fossil sqlite> .exit Although this is harmless, people will ask why there are windows path names visible anyway. This problem is really in SQLite, and the problem is already reported to the SQLite developers: <http://osdir.com/ml/sqlite-users/2014-02/msg00515.html> Since SQLite's Cygwin support is at best-effort base, which appears to be essentially almost 0, I have no idea when this problem will addressed in the official SQLite sources. It is already addressed in the Cygwin SQLite 3.8.5 package. Therefore, I suggest to configure fossil with the option "--disable-internal-sqlite". This has the side-effect that the fossil binary will be smaller, since SQLite is no longer linked statically. And some more - less important - corner-cases will be fixed as well. And it has the advantage that whenever a new bug in SQLite is found (or SQLite 3.8.6 is released) fossil can take advantage of it without being rebuilt. While on it, the "--json" configuration option would be a good idea too. Many thanks, Jari, for your support! Regards, Jan Nijtmans ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] New DLLs and sources. Was: SQLite version 3.8.5 beta
2014-05-29 15:52 GMT+02:00 Len Chisholm <len.chish...@paradise.net.nz>: > I see that the 64-bit MSVC DLL has the correct version resources, which show > in the tool-tip when you hover over the DLL in an Explorer window or look at > the file properties. > I think that I also got the version info when I went through the steps to > compile my own DLL with MSVC a while ago. > However, the latest 32-bit DLL compiled with mingw doesn't include the > version info. MinGW is only supported on best-effort base (unlike MSVC), so I have no idea when Richard will handle this. It's already reported here: <http://osdir.com/ml/sqlite-users/2014-03/msg00591.html> The ML report contains a patch and explanation too. Feel free to try it and ask questions here, I'll try to answer them. > There is a ticket for this in the bug tracker, which I can't find right now, <http://www.sqlite.org/src/tktview?name=f711d5a937> Regards, Jan Nijtmans ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] SQLite version 3.8.5 beta
2014-05-27 1:24 GMT+02:00 Richard Hipp <d...@sqlite.org>:
> Please report any problems to this mailing list and/or directly to me.
$ gcc -DSQLITE_USE_FCNTL_TRACE -c sqlite3.c
sqlite3.c: In function ‘sqlite3VdbeExec’:
sqlite3.c:73742:37: error: expected expression before ‘==’ token
if( MASKBIT(i) & p->btreeMask)==0 ) continue;
^
sqlite3.c:73742:41: error: expected statement before ‘)’ token
if( MASKBIT(i) & p->btreeMask)==0 ) continue;
Bisecting points to this commit:
<http://www.sqlite.org/src/info/87bf60637e>
Regards,
Jan Nijtmans
Index: src/vdbe.c
==
--- src/vdbe.c
+++ src/vdbe.c
@@ -6278,11 +6278,11 @@
#ifdef SQLITE_USE_FCNTL_TRACE
zTrace = (pOp->p4.z ? pOp->p4.z : p->zSql);
if( zTrace ){
int i;
for(i=0; inDb; i++){
- if( MASKBIT(i) & p->btreeMask)==0 ) continue;
+ if( (MASKBIT(i) & p->btreeMask)==0 ) continue;
sqlite3_file_control(db, db->aDb[i].zName, SQLITE_FCNTL_TRACE, zTrace);
}
}
#endif /* SQLITE_USE_FCNTL_TRACE */
#ifdef SQLITE_DEBUG
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] SQLite version 3.8.5 beta
2014-05-27 5:57 GMT+02:00 jose isaias cabrera <cabr...@wrc.xerox.com>: > "Richard Hipp" wrote... >> Please report any problems to this mailing list and/or directly to me. > I am having problem using the pre-built DLL: > http://www.sqlite.org/snapshot/sqlite-dll-win32-x86-201405262205.zip > > I am getting this error: > > ProgName.exe Entry Point Not Found > The procedure entry point FlsAlloc cound not be located in the dynamic Link > library KERNEL32.dll The entry point FlsAlloc doesn't occur anywhere in the sqlite3.c source code, it is generated by Visual Studio. Previous sqlite3.dll versions were generated with MinGW (version 3.17, I guess) that's why they worked fine on Windows XP. If you are interested to try an sqlite3.dll built by the latest MinGW (version 4.0.3), you can have a look here: <https://sourceforge.net/projects/cyqlite/files/> This project is still in the startup phase, but I'm trying to fill the gap Microsoft is leaving behind.. Thanks! Regards, Jan Nijtmans ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Code Error -- Cannot compile Amalgamation with SQLITE_THREADSAFE=0 on WIndows
2014-05-11 12:02 GMT+02:00 Jan Nijtmans <jan.nijtm...@gmail.com>: > 2014-05-11 1:15 GMT+02:00 Keith Medcalf <kmedc...@dessus.com>: >> Somewhere you have removed the Windows.h header from being included where it >> is needed when SQLITE_THREADSAFE is set to 0 resulting in a failure to >> recognize windows defines. >> >> In mutex_w32.c you need to include os_win.h whether or not SQLITE_MUTEX_W32 >> is defined. >> >> In other words the sequence >> >> #ifdef SQLITE_MUTEX_W32 >> #include "os_win.h" >> >> needs to be >> >> #include "os_win.h" >> #ifdef SQLITE_MUTEX_W32 >> >> otherwise windows.h is not included early enough and compilation of the vfs >> fails. > > Confirmed! > > My suggestion (FWIW) would be to remove the os_win.h file > altogether and put it's content in os_config.h. (except the > #ifdef __CYGWIN__ part, which doesn't belong here) > > It's all about configuration isn't it? That's the > simplest way to fix this problem. > > Regards, >Jan Nijtmans /os_config.h/os_setup.h/ (didn't have the sources at-hand) Regards, Jan Nijtmans ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Code Error -- Cannot compile Amalgamation with SQLITE_THREADSAFE=0 on WIndows
2014-05-11 1:15 GMT+02:00 Keith Medcalf <kmedc...@dessus.com>: > Somewhere you have removed the Windows.h header from being included where it > is needed when SQLITE_THREADSAFE is set to 0 resulting in a failure to > recognize windows defines. > > In mutex_w32.c you need to include os_win.h whether or not SQLITE_MUTEX_W32 > is defined. > > In other words the sequence > > #ifdef SQLITE_MUTEX_W32 > #include "os_win.h" > > needs to be > > #include "os_win.h" > #ifdef SQLITE_MUTEX_W32 > > otherwise windows.h is not included early enough and compilation of the vfs > fails. Confirmed! My suggestion (FWIW) would be to remove the os_win.h file altogether and put it's content in os_config.h. (except the #ifdef __CYGWIN__ part, which doesn't belong here) It's all about configuration isn't it? That's the simplest way to fix this problem. Regards, Jan Nijtmans ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] [ANNOUNCEMENT] Updated: sqlite3-3.8.4.3-1 for Cygwin/Cygwin64
SQLite is a software library that implements a self-contained, serverless, zero-configuration, transactional SQL database engine Changes since 3.8.4.1-1 = * Updated to upstream 3.8.4.3 release. See: <http://www.sqlite.org/releaselog/current.html> * One new Cygwin package: "sqlite3-vfslog". This extension can be used to log all vfs activity in CSV format. * Additional bug-fixes, either discovered just after upstream 3.8.4.3 was released, either discovered earlier but not considered important enough to put in the upstream release: * Fix the EXPLAIN indenter in the command-line shell to correctly handle NextIfOpen and PrevIfOpen opcodes. <http://www.sqlite.org/src/info/01944c53f5> * In the command-line shell, run set writable_schema before running the ".clone" command. <http://www.sqlite.org/src/info/9d2ae6342c> * Ensure the "PRAGMA journal_mode=WAL" works coming from any other journal_mode with ATTACH-ed databases. <http://www.sqlite.org/src/info/e54330b431> * Modify the OR-clause handling so that it can safely deal with OR-clause with 17 or more terms. <http://www.sqlite.org/src/info/10fb063b11> * Make sure column cache elements are cleared correctly when jumping over code for key generation in a partial index. <http://www.sqlite.org/src/info/2ea3e9fe63> * Make sure the undocumented sqlite_rename_parent() function does not crash even if it is invoked with NULL arguments. <http://www.sqlite.org/src/info/264b970c43> * Additional SQLite bug-fixes, rejected (apparently) upstream but important (and simple) enough for Cygwin: * VFS filename truncation issues <http://www.sqlite.org/src/info/c060923a54> * Wrong filename handling in sqlite3_load_extension() for Cygwin <http://osdir.com/ml/sqlite-users/2014-02/msg00431.html> * pragma database_list returns win32 paths on Cygwin <http://osdir.com/ml/sqlite-users/2014-02/msg00515.html> -- Jan Nijtmans ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] SQLite ticket [f711d5a937] not fixed.
Hi all,
Three weeks ago SQLite ticket [f711d5a937] was reported
fixed:
<http://www.sqlite.org/src/tktview?name=f711d5a937>
So, I downloaded latest sqlite3.dll (3.8.4.1) from sqlite.org
and right-clicked on it: No version information appeared.
However, it's a small step to really fix it. Here is my
suggested patch. With this patch I succeeded to create
a sqlite3.dll (from curren trunk) with the right version
information in it (3.8.5), using MinGW 4.0 (but it should
work with any MinGW/MinGW-w64 version). The
implementation is mostly copied from Makefile.msc.
Note: the reason for the -static-libgcc option is explained here:
<http://sqlite.1065341.n5.nabble.com/Compiling-SQLite-with-latest-MinGW-undesired-link-to-MinGW-specific-dll-td73985.html>
Regards,
Jan Nijtmans
=
--- Makefile.in
+++ Makefile.in
@@ -995,13 +995,22 @@
REAL_LIBOBJ = $(LIBOBJ:%.lo=.libs/%.o)
$(REAL_LIBOBJ): $(LIBOBJ)
+sqlite3rc.h: $(TOP)/VERSION
+ echo #ifndef SQLITE_RESOURCE_VERSION > sqlite3rc.h
+ echo "#define SQLITE_RESOURCE_VERSION" `cat "$(TOP)\VERSION"` \
+ | $(NAWK) "/.*/ { gsub(/[.]/,\",\");print }" >> sqlite3rc.h
+ echo #endif >> sqlite3rc.h
+
+sqlite3rc.o: $(TOP)/src/sqlite3.rc sqlite3rc.h
+ windres -I$(TOP)/src -I. $(TOP)/src/sqlite3.rc -o $@
+
sqlite3.def: $(REAL_LIBOBJ)
echo 'EXPORTS' >sqlite3.def
nm $(REAL_LIBOBJ) | grep ' T ' | grep ' _sqlite3_' \
| sed 's/^.* _//' >>sqlite3.def
-sqlite3.dll: $(REAL_LIBOBJ) sqlite3.def
- $(TCC) -shared -o $@ sqlite3.def \
+sqlite3.dll: $(REAL_LIBOBJ) sqlite3rc.o sqlite3.def
+ $(TCC) -shared -static-libgcc -o $@ sqlite3rc.o sqlite3.def \
-Wl,"--strip-all" $(REAL_LIBOBJ)
--- src/sqlite3.rc
+++ src/sqlite3.rc
@@ -38,12 +38,12 @@
/*
* Version
*/
VS_VERSION_INFO VERSIONINFO
- FILEVERSION SQLITE_RESOURCE_VERSION
- PRODUCTVERSION SQLITE_RESOURCE_VERSION
+ FILEVERSION SQLITE_RESOURCE_VERSION,0
+ PRODUCTVERSION SQLITE_RESOURCE_VERSION,0
FILEFLAGSMASK VS_FFI_FILEFLAGSMASK
#if defined(_DEBUG)
FILEFLAGS VS_FF_DEBUG
#else
FILEFLAGS VS_FF_NONE
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] WARNING: 'Makefile.in' seems to ignore the --datarootdir setting
When compiling tclsqlite using the TEA build scripts, a warning is displayed:
...
config.status: creating Makefile
config.status: WARNING: 'Makefile.in' seems to ignore the
--datarootdir setting
config.status: creating pkgIndex.tcl
...
Explanation why this happens can be found here:
<http://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/Changed-Directory-Variables.html>
Suggested (trivial) patch below.
Regards,
Jan Nijtmans
Index: autoconf/tea/Makefile.in
==
--- autoconf/tea/Makefile.in
+++ autoconf/tea/Makefile.in
@@ -71,10 +71,11 @@
prefix = @prefix@
exec_prefix= @exec_prefix@
bindir = @bindir@
libdir = @libdir@
+datarootdir= @datarootdir@
datadir= @datadir@
mandir = @mandir@
includedir = @includedir@
DESTDIR=
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Problem compiling SQLite 3.8.4.1 with SQLITE_MAX_MMAP_SIZE=0
2014-03-14 12:06 GMT+01:00 Stephan Beal <sgb...@googlemail.com>: > i posted it to sqlite-dev on Feb. 19th, but Brad was on CC, and maybe that > list elides mails with CCs. Well, I just finished running the test-suite "make test" for the Cygwin64 build of SQLite 3.8.4.1 (with the SQLITE_MAX_MMAP_SIZE=0 fix). For people interested, the following 7 tests had to be excluded because they crash somehow (still to be investigated why): test/multiplex.test test/multiplex2.test test/multiplex3.test test/pager1.test test/pager4.test test/wal2.test test/walnoshm.test The previous test-suite run (SQLite 3.8.3.1, with the same 7 exclusions) had the following result: 104 errors out of 132885 tests Now, I got: 89 errors out of 133018 tests Failures on these tests: backup2-6 crash8-5.1.2 crash8-5.2.2 crash8-5.3.2 crash8-5.4.2 crash8-5.5.2 crash8-5.6.2 crash8-5.7.2 crash8-5.8.2 crash8-5.9.2 delete-8.1 delete-8.2 delete-8.3 delete-8.4 delete-8.5 delete-8.6 filectrl-1.5 incrblob3-7.2 journal2-1.1 journal2-1.2 journal2-1.20 journal2-2.2 journal2-2.4 memsubsys1-4.5 memsubsys1-7.5 quota-2.1.2.1 quota-2.1.4 quota-2.1.5 quota-2.2.2 quota-2.2.3 quota-2.4.1 quota-2.4.2 quota-2.4.3 quota-2.4.4 quota-2.4.99 quota-3.1.4 quota-3.1.5 quota-3.2.6 quota-3.2.7 quota-3.2.8 quota-3.2.9 quota-3.3.1 quota-4.1.7 quota-4.1.8 quota-4.1.10 quota-4.1.11 quota-4.4.4 quota-4.4.6 quota-4.4.7 quota2-1.13 quota2-1.15 quota2-1.16 sync-1.1 sync-1.2 sync-1.3 temptable-6.2 temptable-6.3 temptable-6.6 tkt-f3e5abed55-2.5 uri-1.3.2 uri-1.3.4 uri-1.4.2 uri-1.4.4 uri-2.1.2 uri-2.2.2 uri-2.5.2 uri-2.6.2 uri-2.7.2 uri-2.8.2 uri-2.9.2 uri-2.10.2 uri-2.12.2 wal3-5.3 wal3-5.5 wal3-6.1.4 wal3-6.1.5 wal3-6.1.6 wal3-6.2.3 wal3-6.2.4 wal3-6.2.5 wal3-7.1.3 wal3-7.1.4 wal3-7.2.1 wal3-7.2.2 wal3-8.6 wal3-8.6 zerodamage-2.0 zerodamage-2.1 zerodamage-3.1 All memory allocations freed - no leaks Memory used: now 0 max 126424 max-size 33554304 Allocation count: now 0 max1507718 Page-cache used: now 0 max 13 max-size 65784 Page-cache overflow: now 0 max7639856 Scratch memory used: now 0 max 0 Scratch overflow: now 0 max 74752 max-size 66540 That's 133 test-cases more, but 15 less failing test-cases! That's progress! Give that the Cygwin VFS is built on top of the win32 API, and that I have McAfee running (which tries to interfere too!) that's not bad at all! Regards, Jan Nijtmans ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Problem compiling SQLite 3.8.4.1 with SQLITE_MAX_MMAP_SIZE=0
2014-03-14 11:48 GMT+01:00 Stephan Beal <sgb...@googlemail.com>: > See also this fix: > > http://fossil.wanderinghorse.net/repos/libfossil/index.cgi/info/a9263730f2 > > that's from Brad Harder, for BSD. Hey, that's exactly the same solution! Pity that Brad didn't report that upstream, the fix could have been in SQLite 3.8.4.1 already. Thanks! Regards, Jan Nijtmans ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] Problem compiling SQLite 3.8.4.1 with SQLITE_MAX_MMAP_SIZE=0
Hi all,
I just found out that I was too quick upgrading libfossil to use
the latest SQLite 3.8.4.1 amalgamation:
<http://fossil.wanderinghorse.net/repos/libfossil/index.cgi/info/2de81ae7b6>
this broke the Cygwin build ;-(. The reason is that libfossil is very
strict, considering any warning as error, otherwise I wouldn't even
have noticed this.
CC [obj/sqlite3.o] ...
src/sqlite3.c:52986:20: error: 'sqlite3BtreeSetMmapLimit' defined
but not used [-Werror=unused-function]
SQLITE_PRIVATE int sqlite3BtreeSetMmapLimit(Btree *p,
sqlite3_int64 szMmap){
^
cc1: all warnings being treated as errors
sqlite3.make:18: recipe for target 'obj/sqlite3.o' failed
make: *** [obj/sqlite3.o] Error 1
The problem is that the default SQLITE_MAX_MMAP_SIZE for any
platform not listed is 0. Proposed patch below. Any other platform
with SQLITE_MAX_MMAP_SIZE=0 will give the same warning/error.
I'm sure this change will make more mmap-related test-cases
in the Cygwin test-suite pass, but didn't try that yet..
With this patch, libfossil compiles fine on Cygwin again.
<http://fossil.wanderinghorse.net/repos/libfossil/index.cgi/info/1dff0493d2>
Regards,
Jan Nijtmans
Index: src/btree.c
==
--- src/btree.c
+++ src/btree.c
@@ -2163,18 +2163,20 @@
/*
** Change the limit on the amount of the database file that may be
** memory mapped.
*/
+#if SQLITE_MAX_MMAP_SIZE>0
int sqlite3BtreeSetMmapLimit(Btree *p, sqlite3_int64 szMmap){
BtShared *pBt = p->pBt;
assert( sqlite3_mutex_held(p->db->mutex) );
sqlite3BtreeEnter(p);
sqlite3PagerSetMmapLimit(pBt->pPager, szMmap);
sqlite3BtreeLeave(p);
return SQLITE_OK;
}
+#endif
/*
** Change the way data is synced to disk in order to increase or decrease
** how well the database resists damage due to OS crashes and power
** failures. Level 1 is the same as asynchronous (no syncs() occur and
Index: src/btree.h
==
--- src/btree.h
+++ src/btree.h
@@ -61,11 +61,13 @@
#define BTREE_SINGLE4 /* The file contains at most 1 b-tree */
#define BTREE_UNORDERED 8 /* Use of a hash implementation is OK */
int sqlite3BtreeClose(Btree*);
int sqlite3BtreeSetCacheSize(Btree*,int);
+#if SQLITE_MAX_MMAP_SIZE>0
int sqlite3BtreeSetMmapLimit(Btree*,sqlite3_int64);
+#endif
int sqlite3BtreeSetPagerFlags(Btree*,unsigned);
int sqlite3BtreeSyncDisabled(Btree*);
int sqlite3BtreeSetPageSize(Btree *p, int nPagesize, int nReserve, int eFix);
int sqlite3BtreeGetPageSize(Btree*);
int sqlite3BtreeMaxPageCount(Btree*,int);
Index: src/sqliteInt.h
==
--- src/sqliteInt.h
+++ src/sqliteInt.h
@@ -616,11 +616,11 @@
# define SQLITE_MAX_MMAP_SIZE 0
# endif
#endif
#ifndef SQLITE_MAX_MMAP_SIZE
# if defined(__linux__) \
- || defined(_WIN32) \
+ || defined(_WIN32) || defined(__CYGWIN__) \
|| (defined(__APPLE__) && defined(__MACH__)) \
|| defined(__sun)
# define SQLITE_MAX_MMAP_SIZE 0x7fff /* 2147418112 */
# else
# define SQLITE_MAX_MMAP_SIZE 0
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] failure to build static library with -DSQLITE_ENABLE_ICU
2014-03-14 0:30 GMT+01:00 Alex Loukissas <a...@maginatics.com>: > I have verified that adding the said include fixes the issue (1-line patch): > > diff --git sqlite3.c sqlite3.c > index 7c6d3e2..a9399e4 100644 > --- sqlite3.c > +++ sqlite3.c > @@ -145656,6 +145656,7 @@ SQLITE_API int sqlite3_rtree_init( > #include > #include > #include > +#include > > /* #include */ > > Hope this helps others that run into this issue. This sounds strange to me (I compiled the SQLite ICU extension for Cygwin, and didn't run into this issue). According to the ICU documentation, (which is just above the ) includes , which in turn includes : <http://icu.sourcearchive.com/documentation/4.2/utypes_8h.html> So, the current order of includes should just work fine. What ICU version are you using? I used ICU 4.8 and 5.1, neither of them have the problem you describe. Sorry. Regards, Jan Nijtmans ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] [ANNOUNCEMENT] Updated: sqlite3-3.8.4.1-1 for Cygwin/Cygwin64
SQLite is a software library that implements a self-contained, serverless, zero-configuration, transactional SQL database engine Changes since 3.8.3.1-1 = * Updated to upstream 3.8.4.1 release. See: <http://www.sqlite.org/releaselog/current.html> * Two new Cygwin packages: "sqlite3-icu" and "sqlite3-zlib". They can be loaded dynamically by any application which wants to use those SQLite extensions. In sqlite3.exe this can be done with ".load icu" resp. ".load zlib". See: <http://www.sqlite.org/src/artifact?ci=trunk=ext/icu/README.txt> <http://fossil-scm.org/index.html/artifact/6b4958b9250369d7?ln=53-128> * Additional SQLite bug-fixes, rejected (apparently) upstream: * VFS filename truncation issues <http://www.sqlite.org/src/info/c060923a54> * Wrong filename handling in sqlite3_load_extension() for Cygwin <http://osdir.com/ml/sqlite-users/2014-02/msg00431.html> * pragma database_list returns win32 paths on Cygwin <http://osdir.com/ml/sqlite-users/2014-02/msg00515.html> -- Jan Nijtmans ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] sqlite3.exe file not produced by sqlite-autoconf-3080400.tar.gz on Cygwin
2014-03-11 17:45 GMT+01:00 Keith Christian <keith1christ...@gmail.com>: > Will have to troubleshoot the details of the makefile changes between > the autoconf version from 3.8.3 to 3.8.4, to see why on this Cygwin > environment a "sqlite3.exe" wasn't created. That will be awhile, > pretty busy at $WORK (not a bad thing.) Don't know, but in my Cygwin enviroment everything works fine. The diff's in your first mail indicate the changes in the TEA makefiles, which were adapted to the latest versions in this commit: <http://www.sqlite.org/src/info/b81ba7a4bc> those are used to build the sqlite3 Tcl extension, apparently not what you are after. It works fine for me. Anyway, I just uploaded the SQLite 3.8.4.1 build for Cygwin, it just depends on the mirrors how fast they pick it up. Regards, Jan Nijtmans ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] SQLite version 3.8.4 release schedule
2014-03-06 22:02 GMT+01:00 Larry Brasfield <brasfield.la...@gmail.com>:
> This makes Cygwin unique among all operating systems with which I am
> familiar having support for hierarchical filesystems. Most importantly, if
> true, it would differ from Unixen. I suggest that, in fact, bare
> filenames, (names without any prepended directory path components), ARE
> expected to be found in "the current directory" as that is known to any
> process.
But not in dlopen():
See:
<http://man7.org/linux/man-pages/man3/dlopen.3.html>
Quoting:
If filename contains a slash ("/"), then it
is interpreted as a (relative or absolute) pathname. Otherwise, the
dynamic linker searches for the library as follows (see ld.so(8) for
further details):
I want the dlopen() in the Cygwin VFS to behave the same as other UNIX'es.
Regards,
Jan Nijtmans
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] SQLite version 3.8.4 release schedule
2014-03-05 17:07 GMT+01:00 Richard Hipp <d...@sqlite.org>: > A number of bugs have recently been revealed in SQLite. All are obscure. > Nevertheless, we want to accelerate the release of version 3.8.4 in order > to get the fixes in circulation. Great, I'm looking forward to this! One of the bugs recently discovered was the handling of absolute paths in Cygwin. E.g. when loading an extension <http://osdir.com/ml/sqlite-users/2014-02/msg00515.html> or when using "pragma database_list" <http://osdir.com/ml/sqlite-users/2014-02/msg00431.html> I don't think today's attempt in fixing this is a good idea: <http://www.sqlite.org/src/info/29b0a4f158> Although it fixes the loading of extensions on Cygwin when using absolute paths, it breaks it when using relative paths (bare filenames are NOT expected to be found in the current directory). My recommendation would be to revert this, and - after the SQLite 3.8.4 release - start handling that. So short before a new release it is more risk than that it really helps. The Cygwin package of 3.8.4 will contain another (better IMHO) fix anyway. There is no hurry in applying whatever fix upstream. The MinGW 4.x enhancements works great! Thanks! Jan Nijtmans ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] pragma database_list returns win32 paths on Cygwin
Compiling fossil trunk as-is on Cygwin gives:
$ ./fossil status
repository: /cygdrive/c/fossil/fossil.fossil
local-root: /Localdata/workspace/fossil/
..
$ ./fossil sqlite3
SQLite version 3.8.3.1 2014-02-11 14:52:19
Enter ".help" for usage hints.
sqlite> .databases
seq name file
--- ---
--
0main C:\fossil\fossil.fossil
sqlite> pragma database_list;
0|main|C:\fossil\fossil.fossil
sqlite> .exit
Note that the repository name is reported by fossil as Cygwin path
(which it really is!) but SQLite reports it as win32 path.
This is not as expected, as the fact that the win32 VFS uses win32
paths internally should be transparent. See:
<http://www.sqlite.org/pragma.html#pragma_database_list>
Workaround: compile fossil with --disable-internal-sqlite
(Cygwin's SQLite fork has this problem fixed already, the suggested
winConvertFromUtf8Filename modification is derived from this fix).
Suggested patch below. Using this modified winConvertFromUtf8Filename()
allows various code simplifications in other places, but that's for another day.
Regards,
Jan Nijtmans
Index: src/os_win.c
==
--- src/os_win.c
+++ src/os_win.c
@@ -4127,14 +4127,51 @@
/*
** Convert a UTF-8 filename into whatever form the underlying
** operating system wants filenames in. Space to hold the result
** is obtained from malloc and must be freed by the calling
** function.
+**
+** On Cygwin 1.7 and higher, 3 possible input forms are accepted:
+** - If the filename starts with ":/" or ":\",
+** it is converted to UTF-16 as-is.
+** - If the filename contains '/', it is assumed to be a
+** Cygwin absolute path, it is converted to a win32
+** absolute path in UTF-16.
+** - Otherwise it must be a filename only, the win32 filename
+** is returned in UTF-16.
+** Note: The function cygwin_conv_path does not exist in
+** Cygwin 1.5. Cygwin 1.7 does not run in Windows 95/98/ME.
+** Therefore the !osIsNT() case does not need special handling.
+** Note 2: If the function cygwin_conv_path() fails, only
+** UTF-8 -> UTF-16 conversion will be done. This can only
+** happen when the file path >32k, in which case winUtf8ToUnicode()
+** will fail too.
*/
static void *winConvertFromUtf8Filename(const char *zFilename){
void *zConverted = 0;
if( osIsNT() ){
+#ifdef __CYGWIN__
+if( !(winIsDriveLetterAndColon(zFilename)
+&& winIsDirSep(zFilename[2])) ){
+ int nByte;
+ int convertflag = CCP_POSIX_TO_WIN_W;
+ if( !strchr(zFilename, '/') ) convertflag |= CCP_RELATIVE;
+ nByte = cygwin_conv_path(convertflag,
+ zFilename, 0, 0);
+ if( nByte>0 ){
+zConverted = sqlite3MallocZero(nByte);
+if ( zConverted==0 ){
+ return zConverted;
+}
+if( cygwin_conv_path(convertflag, zFilename,
+ zConverted, nByte)==0 ){
+ return zConverted;
+}
+sqlite3_free(zConverted);
+ }
+}
+#endif
zConverted = winUtf8ToUnicode(zFilename);
}
#ifdef SQLITE_WIN32_HAS_ANSI
else{
zConverted = sqlite3_win32_utf8_to_mbcs(zFilename);
@@ -4961,11 +4998,13 @@
#if defined(__CYGWIN__)
SimulateIOError( return SQLITE_ERROR );
UNUSED_PARAMETER(nFull);
assert( nFull>=pVfs->mxPathname );
- if ( sqlite3_data_directory && !winIsVerbatimPathname(zRelative) ){
+ if( winIsDirSep(zRelative[0]) ){
+sqlite3_snprintf(pVfs->mxPathname, zFull, "%s", zRelative);
+ }else if( sqlite3_data_directory && !winIsVerbatimPathname(zRelative) ){
/*
** NOTE: We are dealing with a relative path name and the data
** directory has been set. Therefore, use it as the basis
** for converting the relative path name to an absolute
** one by prepending the data directory and a slash.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Wrong filename handling in sqlite3_load_extension() for Cygwin
2014-02-20 14:39 GMT+01:00 Jan Nijtmans <jan.nijtm...@gmail.com>:
> The function sqlite3_load_extension() on Cygwin expects a
> win32 path, even though it is compiled for Cygwin.
Here is a new version of my patch which fixes this bug,
which handles better the case that the path does not
contain slashes (just a bare filename). And added comments
to the function winConvertFromUtf8Filename(), making
it clearer what this function is supposed to do in Cygwin 1.7+
I plan to include some standard extensions in the
SQLite 3.8.4 build for Cygwin, this patch is needed
to make dynamical loading work at all on Cygwin.
I hope this patch will be given some time for proper
evaluation, so it can be included in SQLite 3.8.4.
The first chunk in this patch does the actual work,
the last 3 are only optimization, showing how other
code can be simplified when winConvertFromUtf8Filename
is modified to be able to handle Cygwin paths. More
optimizations like this are possible, and will be submitted
as follow-up.
Thanks to Joe for providing feedback at my previous
attempt! I hope this patch makes things clearer.
Regards,
Jan Nijtmans
Index: src/os_win.c
==
--- src/os_win.c
+++ src/os_win.c
@@ -4127,14 +4127,51 @@
/*
** Convert a UTF-8 filename into whatever form the underlying
** operating system wants filenames in. Space to hold the result
** is obtained from malloc and must be freed by the calling
** function.
+**
+** On Cygwin 1.7 and higher, 3 possible input forms are accepted:
+** - If the filename starts with ":/" or ":\",
+** it is converted to UTF-16 as-is.
+** - If the filename contains '/', it is assumed to be a
+** Cygwin absolute path, it is converted to a win32
+** absolute path in UTF-16.
+** - Otherwise it must be a filename only, the win32 filename
+** is returned in UTF-16.
+** Note: The function cygwin_conv_path does not exist in
+** Cygwin 1.5. Cygwin 1.7 does not run in Windows 95/98/ME.
+** Therefore the !osIsNT() case does not need special handling.
+** Note 2: If the function cygwin_conv_path() fails, only
+** UTF-8 -> UTF-16 conversion will be done. This can only
+** happen when the file path >32k, in which case winUtf8ToUnicode()
+** will fail too.
*/
static void *winConvertFromUtf8Filename(const char *zFilename){
void *zConverted = 0;
if( osIsNT() ){
+#ifdef __CYGWIN__
+if( !(winIsDriveLetterAndColon(zFilename)
+&& winIsDirSep(zFilename[2])) ){
+ int nByte;
+ int convertflag = CCP_POSIX_TO_WIN_W;
+ if( !strchr(zFilename, '/') ) convertflag |= CCP_RELATIVE;
+ nByte = cygwin_conv_path(convertflag,
+ zFilename, 0, 0);
+ if( nByte>0 ){
+zConverted = sqlite3MallocZero(nByte);
+if ( zConverted==0 ){
+ return zConverted;
+}
+if( cygwin_conv_path(convertflag, zFilename,
+ zConverted, nByte)==0 ){
+ return zConverted;
+}
+sqlite3_free(zConverted);
+ }
+}
+#endif
zConverted = winUtf8ToUnicode(zFilename);
}
#ifdef SQLITE_WIN32_HAS_ANSI
else{
zConverted = sqlite3_win32_utf8_to_mbcs(zFilename);
@@ -4243,11 +4280,11 @@
/* If the path starts with a drive letter followed by the colon
** character, assume it is already a native Win32 path; otherwise,
** it must be converted to a native Win32 path via the Cygwin API
** prior to using it.
*/
- if( winIsDriveLetterAndColon(zDir) ){
+ if( 1 ){
zConverted = winConvertFromUtf8Filename(zDir);
if( !zConverted ){
sqlite3_free(zBuf);
OSTRACE(("TEMP-FILENAME rc=SQLITE_IOERR_NOMEM\n"));
return SQLITE_IOERR_NOMEM;
@@ -4256,10 +4293,11 @@
sqlite3_snprintf(nMax, zBuf, "%s", zDir);
sqlite3_free(zConverted);
break;
}
sqlite3_free(zConverted);
+#if 0 /* not necessary any more */
}else{
zConverted = sqlite3MallocZero( nMax+1 );
if( !zConverted ){
sqlite3_free(zBuf);
OSTRACE(("TEMP-FILENAME rc=SQLITE_IOERR_NOMEM\n"));
@@ -4290,10 +4328,11 @@
sqlite3_free(zUtf8);
sqlite3_free(zConverted);
break;
}
sqlite3_free(zConverted);
+#endif /* not necessary any more */
}
}
}
#elif !SQLITE_OS_WINRT && !defined(__CYGWIN__)
else if( osIsNT() ){
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] Wrong filename handling in sqlite3_load_extension() for Cygwin
The function sqlite3_load_extension() on Cygwin expects a
win32 path, even though it is compiled for Cygwin.
How to reproduce? First create some extension, e.g.:
gcc -shared -o wholenumber.dll ext/misc/wholenumber.c
Then compile the following little program:
== main.c
#include
#include
void main(int argc, char **argv){
sqlite3 *db;
int rc;
char *zErrMsg = 0;
printf("loading extension: %s\n", argv[1]);
sqlite3_initialize();
sqlite3_open("foo.db", );
sqlite3_enable_load_extension(db, 1);
rc = sqlite3_load_extension(db, argv[1], "sqlite3_wholenumber_init",
);
if( rc!=SQLITE_OK ){
fprintf(stderr, "Error: %s\n", zErrMsg);
sqlite3_free(zErrMsg);
rc = 1;
}
}
gcc main.c sqlite3.c
(This produces an executable "a.exe")
Then try:
$ ./a.exe wholenumber.dll
loading extension: wholenumber.dll
This works, but:
$ ./a.exe $PWD/wholenumber.dll
loading extension: /home/nijtmaj/wholenumber.dll
Error: The specified module could not be found.
Hey, this is exactly where the dll is.
$ ./a.exe `cygpath -w /home/nijtmaj/`wholenumber.dll
loading extension: C:\Localdata\cygwin\home\nijtmaj\wholenumber.dll
When using win32 path, it works! That's not correct!
Suggested patch which fixes this is below. Note
that adding 17 lines to the function
winConvertFromUtf8Filename() means that 38 lines
can be removed from the function winGetTempname():
If we teach winConvertFromUtf8Filename() how to
handle cygwin paths, winGetTempname() doesn't
have to do this conversion any more, just deligate it
to winConvertFromUtf8Filename(). The total
amalgamation becomes 21 lines shorter.
If the function cygwin_conv_path() fails for whatever
reason (which should never happen!), the original path
translation is used as fall-back. This simplifies greatly
the error-handling: if there is something wrong with
the path, everything is cleaned up correctly and
handled exactly as before.
I hope this contribution is still in time for SQLite 3.8.4,
and given some time for proper evaluation.
Regards,
Jan Nijtmans
==
Index: src/os_win.c
==
--- src/os_win.c
+++ src/os_win.c
@@ -4131,10 +4131,27 @@
** function.
*/
static void *winConvertFromUtf8Filename(const char *zFilename){
void *zConverted = 0;
if( osIsNT() ){
+#ifdef __CYGWIN__
+if( !(winIsDriveLetterAndColon(zFilename)
+&& winIsDirSep(zFilename[2])) ){
+ int nByte = cygwin_conv_path(CCP_POSIX_TO_WIN_W, zFilename, 0, 0);
+ if( nByte>0 ){
+zConverted = sqlite3MallocZero(nByte);
+if ( zConverted==0 ){
+ return zConverted;
+}
+if( cygwin_conv_path(CCP_POSIX_TO_WIN_W, zFilename,
+ zConverted, nByte)==0 ){
+ return zConverted;
+}
+sqlite3_free(zConverted);
+ }
+}
+#endif
zConverted = winUtf8ToUnicode(zFilename);
}
#ifdef SQLITE_WIN32_HAS_ANSI
else{
zConverted = sqlite3_win32_utf8_to_mbcs(zFilename);
@@ -4243,11 +4260,11 @@
/* If the path starts with a drive letter followed by the colon
** character, assume it is already a native Win32 path; otherwise,
** it must be converted to a native Win32 path via the Cygwin API
** prior to using it.
*/
- if( winIsDriveLetterAndColon(zDir) ){
+ if( 1 ){
zConverted = winConvertFromUtf8Filename(zDir);
if( !zConverted ){
sqlite3_free(zBuf);
OSTRACE(("TEMP-FILENAME rc=SQLITE_IOERR_NOMEM\n"));
return SQLITE_IOERR_NOMEM;
@@ -4256,10 +4273,11 @@
sqlite3_snprintf(nMax, zBuf, "%s", zDir);
sqlite3_free(zConverted);
break;
}
sqlite3_free(zConverted);
+#if 0 /* not necessary any more */
}else{
zConverted = sqlite3MallocZero( nMax+1 );
if( !zConverted ){
sqlite3_free(zBuf);
OSTRACE(("TEMP-FILENAME rc=SQLITE_IOERR_NOMEM\n"));
@@ -4290,10 +4308,11 @@
sqlite3_free(zUtf8);
sqlite3_free(zConverted);
break;
}
sqlite3_free(zConverted);
+#endif /* not necessary any more */
}
}
}
#elif !SQLITE_OS_WINRT && !defined(__CYGWIN__)
else if( osIsNT() ){
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] Compiling SQLite with latest MinGW: undesired link to MinGW-specific dll.
When compiled SQLite out-of-the-box on MinGW-4.0 there are two problems. One is currently in progress on the "mingw4x" branch, but there is one more. For explanation and a suggested fix, see below. When compiling sqlite3.dll, it contains a link to libgcc_s_dw2-1.dll, which must be distributed together with sqlite3.dll. Dit is - of course - not desired. A workaround is easy: Add the option "-static-libgcc" in the link line. Earlier MinGW versions only had a static gcc library, so it is safe to use this option always: In MinGW 3 "-static-libgcc" was the default anyway. Most recent MinGW-w64 versions have exactly the same problem, only the required dll name is different (libgcc_s_sjlj-1.dll). This solution works for MinGW-w64 as well. This bug is already reported to MinGW, for details: <https://sourceforge.net/p/mingw/bugs/2065/> Regards, Jan Nijtmans === --- Makefile.in +++ Makefile.in @@ -1001,7 +1001,7 @@ echo 'EXPORTS' >sqlite3.def nm $(REAL_LIBOBJ) | grep ' T ' | grep ' _sqlite3_' \ | sed 's/^.* _//' >>sqlite3.def sqlite3.dll: $(REAL_LIBOBJ) sqlite3.def - $(TCC) -shared -o $@ sqlite3.def \ + $(TCC) -shared -static-libgcc -o $@ sqlite3.def \ -Wl,"--strip-all" $(REAL_LIBOBJ) ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] HTML Tokenizer
2014-02-13 21:35 GMT+01:00 Petite Abeille <petite.abei...@gmail.com>: > > On Feb 13, 2014, at 9:08 PM, Petite Abeille <petite.abei...@gmail.com> wrote: > >> curl -s http://www.sqlite.org | lynx -nolist -stdin -dump > > While we are at it, www.sqlite.org exhibits many validation errors: > > http://validator.w3.org/check?uri=http%3A%2F%2Fwww.sqlite.org%2F=%28detect+automatically%29=Inline=0=W3C_Validator%2F1.3+http%3A%2F%2Fvalidator.w3.org%2Fservices#result But if you put the validator in HTML5 mode, there are many less errors: <http://validator.w3.org/check?uri=http%3A%2F%2Fwww.sqlite.org%2F=%28detect+automatically%29=HTML5=0=W3C_Validator%2F1.3+http%3A%2F%2Fvalidator.w3.org%2Fservices> Regards, Jan Nijtmans ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] [ANNOUNCEMENT] Updated: sqlite3-3.8.3.1-1 for Cygwin/Cygwin64
SQLite is a software library that implements a self-contained, serverless, zero-configuration, transactional SQL database engine Changes since 3.8.3-2 = * Updated to upstream 3.8.3.1 release. See: <http://www.sqlite.org/releaselog/current.html> * One additional bug-fix in "sqlite3-tcl", which was causing crashes during error-handling in Cygwin64: <http://www.sqlite.org/src/info/ea4d23d1c0> Planning SQLite 3.8.4 for Cygwin. == At this moment, Cygwin applications can make use of two different VFS'es: "win32-longpath" or "unix-cygwin", the latter is the default. Both of them have a defect the other one doesn't have: "win32-longpath" doesn't handle Cygwin paths correctly in all situations, and "unix-cygwin" doesn't handle virus-scanner attacks (causing locking errors when using McAfee) that well. Therefore I am working on adaptations improving this situation, I hope this to be ready when SQLite 3.8.4 is released. -- Jan Nijtmans ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] Redundant #define's in os_unix.c
Hi all, In src/os_unix.c line 105, _LARGE_FILE is defined if SQLITE_DISABLE_LFS is not defined. But before that, is included, which contains exactly the same #defines already. This means that _LARGE_FILE will be defined twice. Most likely, one day in the past this code moved from os_unix.c to sqliteInt.h, but it was never removed from the original location. Therefore I suggest to remove this duplication in os_unix.c, leaving everything (including the later-added comment) in sqliteInt.h. Proposed patch below. Hopefully this resolves the confusion for people (like me) who notice this. And, when comments change, they don't need to be updated in two places any more. Regards, Jan Nijtmans == --- src/sqliteInt.h +++ src/sqliteInt.h @@ -32,10 +32,15 @@ ** without this option, LFS is enable. But LFS does not exist in the kernel ** in Red Hat 6.0, so the code won't work. Hence, for maximum binary ** portability you should omit LFS. ** ** Similar is true for Mac OS X. LFS is only supported on Mac OS X 9 and later . +** +** The previous paragraph was written in 2005. (This paragraph is written +** on 2008-11-28.) These days, all Linux kernels support large files, so +** you should probably leave LFS enabled. But some embedded platforms might +** lack LFS in which case the SQLITE_DISABLE_LFS macro might still be useful. */ #ifndef SQLITE_DISABLE_LFS # define _LARGE_FILE 1 # ifndef _FILE_OFFSET_BITS # define _FILE_OFFSET_BITS 64 --- src/os_unix.c +++ src/os_unix.c @@ -81,36 +81,10 @@ # else #define OS_VXWORKS 0 # endif #endif -/* -** These #defines should enable >2GB file support on Posix if the -** underlying operating system supports it. If the OS lacks -** large file support, these should be no-ops. -** -** Large file support can be disabled using the -DSQLITE_DISABLE_LFS switch -** on the compiler command line. This is necessary if you are compiling -** on a recent machine (ex: RedHat 7.2) but you want your code to work -** on an older machine (ex: RedHat 6.0). If you compile on RedHat 7.2 -** without this option, LFS is enable. But LFS does not exist in the kernel -** in RedHat 6.0, so the code won't work. Hence, for maximum binary -** portability you should omit LFS. -** -** The previous paragraph was written in 2005. (This paragraph is written -** on 2008-11-28.) These days, all Linux kernels support large files, so -** you should probably leave LFS enabled. But some embedded platforms might -** lack LFS in which case the SQLITE_DISABLE_LFS macro might still be useful. -*/ -#ifndef SQLITE_DISABLE_LFS -# define _LARGE_FILE 1 -# ifndef _FILE_OFFSET_BITS -# define _FILE_OFFSET_BITS 64 -# endif -# define _LARGEFILE_SOURCE 1 -#endif - /* ** standard include files. */ #include #include ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] Unit-test failure in SQLite (64-bit)
When running the SQLite unit-tests on Cygwin64
(but the same is expected to happen on any
64-bit UNIX-like system):
$ .libs/testfixture.exe test/tclsqlite.test
tcl-1.1... Ok
tcl-1.2... Ok
tcl-1.2.1...Segmentation fault (core dumped)
The cause of this crash is the Tcl function
Tcl_AppendResult(), which expects a 64-bit
NULL-pointer as last argument. But tclsqlite.c
uses 0 here, which is a 32-bit integer. The
compiler cannot know this, because the function
has a variable number of arguments.
Below's patch fixes this specific unit-test failure.
Many other Tcl_AppendResult() calls make the same
mistake, but in many other places it is done correctly.
The change from Tcl_GetStringFromObj() to
Tcl_GetString() is just meant to shorten the
line length: since the second argument is 0,
those are equivalent.
Regards,
Jan Nijtmans
--- src/tclsqlite.c
+++ src/tclsqlite.c
@@ -1835,11 +1835,11 @@
pDb->maxStmt = n;
}
}
}else{
Tcl_AppendResult( interp, "bad option \"",
- Tcl_GetStringFromObj(objv[2],0), "\": must be flush or size", 0);
+ Tcl_GetString(objv[2]), "\": must be flush or size", (char *)0);
return TCL_ERROR;
}
break;
}
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] [ANNOUNCEMENT] Updated: sqlite3-3.8.3-2 for Cygwin/Cygwin64
SQLite is a software library that implements a self-contained, serverless, zero-configuration, transactional SQL database engine Changes since 3.8.2-3 = * Updated to upstream 3.8.3 release. Main feature: Added support for CTE (Common Table Expressions) and Recursive Queries. For a complete list, see: <http://www.sqlite.org/releaselog/current.html> * Is compiled with SQLITE_ENABLE_SQLLOG enabled. See: <http://www.sqlite.org/compile.html#enable_sqllog> * New sub-package "sqlite3-tcl", containing the language bindings for Tcl 8.5/8.6 -- Jan Nijtmans ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] "PRAGMA data_store_directory" inconsistancies
Noting that:
- In src/pragma.c line 1267 can be seen that this PRAGMA
is only expected to exist when SQLITE_OS_WIN==1
- In src/pragma.c line 149, the pragma is eliminated when
SQLITE_OMIT_PAGER_PRAGMAS is defined. This
looks wrong to me.
- On Cygwin, one of the functions exported from the
dll is "sqlite3_win32_set_directory". As this function
is only expected to work on win32, and is documented
to accept an Unicode win32 path, this is not logical.
Therefore, I suggest to correct the
SQLITE_OMIT_PAGER_PRAGMAS check,
and eliminate the Cygwin code which handles
this pragma: Since Cygwin is supposed to
behave like UNIX, even though it uses the "win32"
VFS, there is no reason at all to support this pragma
on Cygwin.
Cygwin's current SQLite 3.8.3-1 (beta) package
already contains those suggested modifications.
Suggested patch follows.
Regards,
Jan Nijtmans
Index: src/pragma.c
==
--- src/pragma.c
+++ src/pragma.c
@@ -144,11 +144,11 @@
{ /* zName: */ "count_changes",
/* ePragTyp: */ PragTyp_FLAG,
/* ePragFlag: */ 0,
/* iArg: */ SQLITE_CountRows },
#endif
-#if !defined(SQLITE_OMIT_PAGER_PRAGMAS) && SQLITE_OS_WIN
+#if SQLITE_OS_WIN && !defined(__CYGWIN__)
{ /* zName: */ "data_store_directory",
/* ePragTyp: */ PragTyp_DATA_STORE_DIRECTORY,
/* ePragFlag: */ 0,
/* iArg: */ 0 },
#endif
@@ -1262,10 +1262,10 @@
#endif /* SQLITE_OMIT_WSD */
}
break;
}
-#if SQLITE_OS_WIN
+#if SQLITE_OS_WIN && !defined(__CYGWIN__)
/*
** PRAGMA data_store_directory
** PRAGMA data_store_directory = ""|"directory_name"
**
Index: src/os_win.c
==
--- src/os_win.c
+++ src/os_win.c
@@ -1662,10 +1662,11 @@
zFilenameMbcs = winUnicodeToMbcs(zTmpWide);
sqlite3_free(zTmpWide);
return zFilenameMbcs;
}
+#if !defined(__CYGWIN__)
/*
** This function sets the data directory or the temporary directory based on
** the provided arguments. The type argument must be 1 in order to set the
** data directory or 2 in order to set the temporary directory. The zValue
** argument is the name of the directory to use. The return value will be
@@ -1698,10 +1699,11 @@
*ppDirectory = zValueUtf8;
return SQLITE_OK;
}
return SQLITE_ERROR;
}
+#endif /* __CYGWIN__ */
/*
** The return value of winGetLastErrorMsg
** is zero if the error message fits in the buffer, or non-zero
** otherwise (if the message was truncated).
@@ -4958,43 +4960,15 @@
int nFull,/* Size of output buffer in bytes */
char *zFull /* Output buffer */
){
#if defined(__CYGWIN__)
+ char *zOut;
SimulateIOError( return SQLITE_ERROR );
UNUSED_PARAMETER(nFull);
assert( nFull>=pVfs->mxPathname );
- if ( sqlite3_data_directory && !winIsVerbatimPathname(zRelative) ){
-/*
-** NOTE: We are dealing with a relative path name and the data
-** directory has been set. Therefore, use it as the basis
-** for converting the relative path name to an absolute
-** one by prepending the data directory and a slash.
-*/
-char *zOut = sqlite3MallocZero( pVfs->mxPathname+1 );
-if( !zOut ){
- return SQLITE_IOERR_NOMEM;
-}
-if( cygwin_conv_path(
-(osIsNT() ? CCP_POSIX_TO_WIN_W : CCP_POSIX_TO_WIN_A) |
-CCP_RELATIVE, zRelative, zOut, pVfs->mxPathname+1)<0 ){
- sqlite3_free(zOut);
- return winLogError(SQLITE_CANTOPEN_CONVPATH, (DWORD)errno,
- "winFullPathname1", zRelative);
-}else{
- char *zUtf8 = winConvertToUtf8Filename(zOut);
- if( !zUtf8 ){
-sqlite3_free(zOut);
-return SQLITE_IOERR_NOMEM;
- }
- sqlite3_snprintf(MIN(nFull, pVfs->mxPathname), zFull, "%s%c%s",
- sqlite3_data_directory, winGetDirSep(), zUtf8);
- sqlite3_free(zUtf8);
- sqlite3_free(zOut);
-}
- }else{
-char *zOut = sqlite3MallocZero( pVfs->mxPathname+1 );
+ zOut = sqlite3MallocZero( pVfs->mxPathname+1 );
if( !zOut ){
return SQLITE_IOERR_NOMEM;
}
if( cygwin_conv_path(
(osIsNT() ? CCP_POSIX_TO_WIN_W : CCP_POSIX_TO_WIN_A),
@@ -5010,11 +4984,10 @@
}
sqlite3_snprintf(MIN(nFull, pVfs->mxPathname), zFull, "%s", zUtf8);
sqlite3_free(zUtf8);
sqlite3_free(zOut);
}
- }
return SQLITE_OK;
#endif
#if (SQLITE_OS_WINCE || SQLITE_OS_WINRT) && !defined(__CYGWIN__)
SimulateIOError( return SQLITE_ERROR );
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Clang 3.3 and Scan-Build results
2014/1/23 Richard Hipp <d...@sqlite.org>:
> At this point you are likely to find lots of compiler warnings. Do not
> worry about those. I'm looking for incorrect behavior and/or bad
> query-planner decisions, not compiler warnings. We'll deal with the
> compiler warnings over the coming weeks.
When building tclsqlite.c using the (unmodified) TEA makefiles
on Cygwin (using --with-system-sqlite), I see many warnings like:
/usr/src/sqlite3/sqlite3-3.8.3-1/src/tea/generic/tclsqlite3.c: In
function ‘auth_callback’:
/usr/src/sqlite3/sqlite3-3.8.3-1/src/tea/generic/tclsqlite3.c:893:42:
warning: assignment discards ‘const’ qualifier from pointer target
type [enabled by default]
case SQLITE_COPY : zCode="SQLITE_COPY"; break;
^
And I would like to suggest to change the reference to the
"sqlite3_version" global variable into "sqlite3_libversion()":
Some platforms (e.g. Windows) don't handle accessing
global variables from other modules very well, using
functions is more portable.
Suggested patch below. With that, all warnings are gone.
In additon, I would change all CONST's to const's, as
tclsqlite.c already uses "const" in may places, and
Tcl doesn't support C-compilers without the "const"
keyword anyway.
Regards,
Jan Nijtmans
Index: src/tclsqlite.c
==
--- src/tclsqlite.c
+++ src/tclsqlite.c
@@ -871,11 +871,11 @@
const char *zArg1,
const char *zArg2,
const char *zArg3,
const char *zArg4
){
- char *zCode;
+ const char *zCode;
Tcl_DString str;
int rc;
const char *zReply;
SqliteDb *pDb = (SqliteDb*)pArg;
if( pDb->disableAuth ) return SQLITE_OK;
@@ -997,11 +997,11 @@
static int DbTransPostCmd(
ClientData data[], /* data[0] is the Sqlite3Db* for $db */
Tcl_Interp *interp, /* Tcl interpreter */
int result /* Result of evaluating SCRIPT */
){
- static const char *azEnd[] = {
+ static const char *const azEnd[] = {
"RELEASE _tcl_transaction",/* rc==TCL_ERROR, nTransaction!=0 */
"COMMIT", /* rc!=TCL_ERROR, nTransaction==0 */
"ROLLBACK TO _tcl_transaction ; RELEASE _tcl_transaction",
"ROLLBACK" /* rc==TCL_ERROR, nTransaction==0 */
};
@@ -1935,11 +1935,11 @@
}else if( objc==2 ){
if( pDb->zCommit ){
Tcl_AppendResult(interp, pDb->zCommit, 0);
}
}else{
- char *zCommit;
+ const char *zCommit;
int len;
if( pDb->zCommit ){
Tcl_Free(pDb->zCommit);
}
zCommit = Tcl_GetStringFromObj(objv[2], );
@@ -2008,18 +2008,18 @@
int nSep; /* Number of bytes in zSep[] */
int nNull; /* Number of bytes in zNull[] */
char *zSql; /* An SQL statement */
char *zLine;/* A single line of input from the file */
char **azCol; /* zLine[] broken up into columns */
-char *zCommit; /* How to commit changes */
+const char *zCommit;/* How to commit changes */
FILE *in; /* The input file */
int lineno = 0; /* Line number of input file */
char zLineNum[80]; /* Line number print buffer */
Tcl_Obj *pResult; /* interp result */
-char *zSep;
-char *zNull;
+const char *zSep;
+const char *zNull;
if( objc<5 || objc>7 ){
Tcl_WrongNumArgs(interp, 2, objv,
"CONFLICT-ALGORITHM TABLE FILENAME ?SEPARATOR? ?NULLINDICATOR?");
return TCL_ERROR;
}
@@ -2933,11 +2933,11 @@
#endif
if( objc==2 ){
zArg = Tcl_GetStringFromObj(objv[1], 0);
if( strcmp(zArg,"-version")==0 ){
- Tcl_AppendResult(interp,sqlite3_version,0);
+ Tcl_AppendResult(interp,sqlite3_libversion(),0);
return TCL_OK;
}
if( strcmp(zArg,"-has-codec")==0 ){
#ifdef SQLITE_HAS_CODEC
Tcl_AppendResult(interp,"1",0);
@@ -3015,11 +3015,11 @@
return TCL_ERROR;
}
zErrMsg = 0;
p = (SqliteDb*)Tcl_Alloc( sizeof(*p) );
if( p==0 ){
-Tcl_SetResult(interp, "malloc failed", TCL_STATIC);
+Tcl_SetResult(interp, (char *)"malloc failed", TCL_STATIC);
return TCL_ERROR;
}
memset(p, 0, sizeof(*p));
zFile = Tcl_GetStringFromObj(objv[2], 0);
zFile = Tcl_TranslateFileName(interp, zFile, );
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] [ANNOUNCEMENT] Updated: sqlite3-3.8.3-1 (beta, as test package) for Cygwin/Cygwin64
SQLite is a software library that implements a self-contained, serverless, zero-configuration, transactional SQL database engine Changes since 3.8.2-3 = * Updated to upstream 3.8.3 beta release. Main feature: Added support for CTE (Common Table Expressions) and Recursive Queries. For a complete list, see: <http://www.sqlite.org/draft/releaselog/current.html> * Is compiled with SQLITE_ENABLE_SQLLOG enabled. See: <http://www.sqlite.org/compile.html#enable_sqllog> * New sub-package "sqlite3-tcl", containing the language bindings for Tcl 8.5/8.6 (works fine with SQLite 3.8.2 as well) Since this is a test package, this beta release is not installed automatically when running setup.exe. You must explicitly specify version 3.8.3-1! -- Jan Nijtmans ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] SQLITE 3.8.3 beta: SQLITE_OMIT_CTE build doesn't work
2014/1/20 Richard Hipp <d...@sqlite.org>:
> That single-macro fix allows it to compile and run. But there are memory
> leaks associated with that fix that would need to be plugged before we
> could use it in a release.
Well, I didn't think about memory leaks Never mind. Since CTE doesn't
make much difference in library size (only 5Kb on x86_64), I don't know if
anyone would actually want CTE to be removed. I just tried it out of curiosity.
Thanks!
Jan Nijtmans
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] SQLITE 3.8.3 beta: SQLITE_OMIT_CTE build doesn't work
2014/1/20 Dan Kennedy <danielk1...@gmail.com>: > Looks like SQLITE_OMIT_CTE only works with full source builds, not > the amalgamation. As it causes code to be omitted from parse.y. > > There are a few others this is true of as well - OMIT_VIRTUALTABLE, > OMIT_TRIGGER etc. Sure, but since addition of a single macro fixes this, I would say: why not fixing it? But - of course- that's up to you. Regards, Jan Nijtmans ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] SQLITE 3.8.3 beta: SQLITE_OMIT_CTE build doesn't work
$ gcc -c -Wall -o sqlite3.o -DSQLITE_OMIT_CTE sqlite3.c sqlite3.c: In function ‘yy_reduce’: sqlite3.c:117782:3: warning: implicit declaration of function ‘sqlite3WithAdd’ [-Wimplicit-function-declaration] yygotominor.yy59 = sqlite3WithAdd(pParse, 0, [-5].minor.yy0, yymsp[-4].minor.yy14, yymsp[-1].minor.yy3); ^ sqlite3.c:117782:20: warning: assignment makes pointer from integer without a cast [enabled by default] yygotominor.yy59 = sqlite3WithAdd(pParse, 0, [-5].minor.yy0, yymsp[-4].minor.yy14, yymsp[-1].minor.yy3); ^ sqlite3.c:117787:20: warning: assignment makes pointer from integer without a cast [enabled by default] yygotominor.yy59 = sqlite3WithAdd(pParse, yymsp[-7].minor.yy59, [-5].minor.yy0, yymsp[-4].minor.yy14, yymsp[-1].minor.yy3); ^ Suggested fix: $ fossil diff --from trunk sqliteInt.h --- sqliteInt.h +++ sqliteInt.h @@ -3357,10 +3357,12 @@ void sqlite3WithDelete(sqlite3*,With*); void sqlite3WithPush(Parse*, With*, u8); #else #define sqlite3WithPush(x,y,z) #define sqlite3WithDelete(x,y) +#define sqlite3WithAdd(p,w,t,x,y) (sqlite3ErrorMsg((p), \ +"near \"%T\": syntax error", (t)),(With*)(w)) #endif /* Declarations for functions in fkey.c. All of these are replaced by ** no-op macros if OMIT_FOREIGN_KEY is defined. In this case no foreign ** key functionality is available. If OMIT_TRIGGER is defined but ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] "Common Table Expression"
2013/12/31 big stone <stonebi...@gmail.com>: > Hello "CTE in SQLite" fans, > > To get CTE in SQLite, I guess we must answer by the example the fears > expressed by Simon and Rsmith. Not necessary. I noticed that CTE was just merged to SQLite's trunk, so it apparently will be part of SQLite 2.8.3. I'm not familiar with CTE, I didn't try it yet, just had a quick glance at the code. I'm wondering if there isn't a #define missing here (see patch below): Regards, Jan Nijtmans Index: src/sqliteInt.h == --- src/sqliteInt.h +++ src/sqliteInt.h @@ -3355,10 +3355,11 @@ #ifndef SQLITE_OMIT_CTE With *sqlite3WithAdd(Parse*,With*,Token*,ExprList*,Select*); void sqlite3WithDelete(sqlite3*,With*); void sqlite3WithPush(Parse*, With*, u8); #else +#define sqlite3WithAdd(x,y,z,z1,z2) #define sqlite3WithPush(x,y,z) #define sqlite3WithDelete(x,y) #endif /* Declarations for functions in fkey.c. All of these are replaced by ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] [ANNOUNCE] Updated: sqlite3-3.8.2-3 for Cygwin/Cygwin64
SQLite is a software library that implements a self-contained,
serverless, zero-configuration, transactional SQL database engine
Changes since 3.8.2-2
=
* Added full Unicode support to the sqlite3 utility, by linking it
with the icu extension statically. Therefore requires libicu as
additional dependency (for sqlite3 only, not for libsqlite3_0)
* Added "compress" and "uncompress" SQL functions to
sqlite3 utility. Therefore requires zlib0 as additional
dependancy (again: for sqlite3 only, not for libsqlite3_0)
* Add the build of new "tcl-sqlite3" package to the source
package (binaries not available yet).
* The following 5 bug-fixes, which are all backported from
SQLite 3.8.3 alpha (in chronological order):
- Fix "Array overrun in the skip-scan optimization"
See: <http://www.sqlite.org/src/info/520070ec7fbaac>
- Fix a bug in the shell ".import" command: Do not end the field
when an escaped double-quote occurs at the end of a CRNL line.
See: <http://www.sqlite.org/src/info/5e239ecda0>
- Fix the ".echo on" dot-command of the shell so that it echos
comments in addition to SQL statements and dot-commands
See: <http://www.sqlite.org/src/info/96397263f9>
- Correct the VFS name as reported by the file control when
explicitly using the 'win32-longpath' VFS.
See: <http://www.sqlite.org/src/info/c43b59dac1>
- Fix "SQLite3 temporary filename collision in worker processes":
See: <https://www.mail-archive.com/sqlite-users@sqlite.org/msg81284.html>
Regards,
Jan Nijtmans
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] SQLite 2013 retrospective
2013/12/31 Richard Hipp <d...@sqlite.org>: > Here is a quick summary of the changes and enhancements to SQLite during > 2013. The comparison is between trunk versions, > http://www.sqlite.org/src/info/a611c75 versus > http://www.sqlite.org/src/info/cc72c5aec7 ... > Major new features added in 2013 include: > >1. Memory-mapped I/O: http://www.sqlite.org/mmap.html >2. The next-generation query planner: > http://www.sqlite.org/queryplanner-ng.html >3. Partial indices: http://www.sqlite.org/partialindex.html >4. WITHOUT ROWID tables: http://www.sqlite.org/withoutrowid.html Also worth to mention: New VFS's: 1. win32-longpath 2. unix-cygwin (Ok. Ok, the latter is not in the officlal SQLite sources yet, but it's available as official Cygwin package and I hope to be able to contribute this in 2014.) > Happy New Year to all. Seconded: Happy New Year to all. Jan Nijtmans ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] An "unable to open database file" error that has nothing to do with opening database file
2013/12/17 margave <margr...@mail.com>: > Well, I gave up on sqlite inside of Cygwin. > > I found a standalone sqlite3.exe that does not depend upon (or install with) > Cygwin. > It's from http://www.sqlite.org > One executable, no .dlls ... and it just runs, no problems. I think I know what's the problem: The SQLite version included in Fossil 1.27 had a bug in the calculation of the temp path: It should be "/tmp/etilqs." but the slash was missing, so actual temporary files were named "/tmpetilqs.". Whether it works or not depends on your rights on the '/' directory. Workaround: Create a dummy directory "foo" inside /tmp, and set the SQLITE_TMPDIR environment variable to "/tmp/foo". Then temporary files should be created in the right directory (even though the name is not right) which should make it work. This SQLite bug is already fixed here: <http://www.sqlite.org/src/info/830629d31d> so next fossil version should be OK. Thanks! Jan Nijtmans ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] An "unable to open database file" error that has nothing to do with opening database file
2013/12/17 margave <margr...@mail.com>: > Well, I gave up on sqlite inside of Cygwin. > > I found a standalone sqlite3.exe that does not depend upon (or install with) > Cygwin. > It's from http://www.sqlite.org > One executable, no .dlls ... and it just runs, no problems. For most situation, indeed this .exe should work fine. Still I'm sure that Jari Aalto (Cygwin's fossil maintainer) will be interested to know what's the problem. I regularly compile Fossil on Cygwin, and I don't see the problems you mention. Anyway, Thanks for your report! Jan Nijtmans ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] An "unable to open database file" error that has nothing to do with opening database file
2013/12/15 margave <margr...@mail.com>: > I noticed that the sqlite3.exe file on computer A has a different cksum than > the one on computer B. (Seems odd! The Cygwin installer shows the same > version on both!) Which version? SQLite 3.8.2-2? Apparently, you are running Cygwin on A and Cygwin64 on B. SQLite is compiled with exactly the same source-code on Cygwin and Cygwin64, but with a different compiler. So this suggests it isn't a problem in SQLite but either in the compiler (unlikely), ore in cygwin1.dll. Hard to tell without some more information. You could try "sqlite3 -vfs win32-longpath" which uses the win32 API in stead of the cygwin API to open the file. Does this make a difference? Regards, Jan Nijtmans ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] [ANNOUNCEMENT] Updated: sqlite3-3.8.2-2 for Cygwin/Cygwin64
SQLite is a software library that implements a self-contained, serverless, zero-configuration, transactional SQL database engine Changes since 3.8.1-1 = * Updated to upstream 3.8.2 release. Main features: * Added support for WITHOUT ROWID tables. * Extend the maximum path length from 512 to 4096 for all VFS's except "win32". * New VFS "unix-namedsem". * Since the dll is compiled with -DSQLITE_ENABLE_EXPLAIN_COMMENTS, the .expain command now gives more useful output than in earlier releases. -- Jan Nijtmans ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] [ANNOUNCEMENT] Updated: sqlite3-3.8.2-1 (beta, as test package) for Cygwin/Cygwin64
SQLite is a software library that implements a self-contained, serverless, zero-configuration, transactional SQL database engine Changes since 3.8.1-1 = * Updated to upstream 3.8.2 beta release. Main feature: * Added support for WITHOUT ROWID tables. * The path handing in the win32/win32-longpath VFS is corrected w.r.t. UTF-8 and db handle sharing. Since "winnt" is the default VFS, no-one should be affected by that. Since this is a test package, this beta release is not installed automatically when running setup.exe. You must explicitly specify version 3.8.2-1! -- Jan Nijtmans ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Visual Studio 2013 Issue - GetVersionEx deprecated
2013/11/4 Jan Nijtmans: > 2013/11/4 Simon Slavin: >> On 4 Nov 2013, at 6:32am, David de Regt <dav...@mylollc.com> wrote: >>> In Visual Studio 2013, which uses the Windows 8.1 Platform SDK, they've >>> marked GetVersionEx as deprecated, trying to supercede it through to >>> VerifyVersionInfo and some other hardcoded macros based on that call that >>> the new SDK implements. Looking at the SQLite source, it looks like it >>> only uses the GetVersionEx call to test for whether LockFileEx is supported >>> on the current OS (whether it's NT-based or not). >> >> Could you suggest equivalent code which would use VerifyVersionInfo instead >> ? Even a rough guide on where to find documentation on it would be useful. Simon, Your request has been granted: <http://www.sqlite.org/src/info/afdca29966> (even though it just missed the beta) Regards, Jan Nijtmans ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
