Re: [sqlite] CVE's opened on 3.30.1 status
Thanks a lot for the prompt response, As far as I found in Fossil repository fixes for all CVE's , excepting erroneously submitted CVE-2019-19646, were merged to Fossil. Can you please estimate next official release of SQLite including these fixes? Regards, Alex -Original Message- From: drhsql...@gmail.com On Behalf Of Richard Hipp Sent: Tuesday, December 24, 2019 6:31 PM To: SQLite mailing list Cc: Raitses, Alex Subject: Re: [sqlite] CVE's opened on 3.30.1 status On 12/24/19, Raitses, Alex wrote: > Hi, > Can you please update on status of the following CVE’s submitted on 3.30.1? > CVE’s link to patches references GitHub branch, however I could find > corresponding submits to Fossil repository. > CVE’s list: > https://nvd.nist.gov/vuln/detail/CVE-2019-19244 > https://nvd.nist.gov/vuln/detail/CVE-2019-19603 > https://nvd.nist.gov/vuln/detail/CVE-2019-19242 > https://nvd.nist.gov/vuln/detail/CVE-2019-19646 > https://nvd.nist.gov/vuln/detail/CVE-2019-19645 None of these CVEs describe actual vulnerabilities, at least not for the typical use-case for SQLite. If you have an unusual application in which you allow unauthenticated users to submit arbitrary SQL to your application, then four of these CVEs describe a denial-of-service opportunity to an attacker. In other words, an attacker who can present arbitrary SQL queries (and DDL statements) to the application can cause the application to crash. Not many applications fall into that category, though. The only application that I know of that does this is the Chrome web-browser. How does your application use SQLite? Do you allow anonymous attackers to present arbitrary SQL to your application? If not, then none of this applies to you. The CVE-2019-19646 describes a bug in a new feature of SQLite that has not yet been released. CVE-2019-19646 was apparently submitted in error. Unfortunately, we do not know of any mechanism to correct erroneous CVEs. Do you? All of the problems described by the CVEs you list have been fixed. In fact, most of the CVEs you list point to the check-in that fixes the problem, in a GitHub mirror of the SQLite repository. The SQLite developers do not issue or track CVEs. CVEs against SQLite are issued by third-parties, typically third-parties who are running fuzzers against the SQLite, and usually without the consultation or approval of the SQLite developers. -- D. Richard Hipp d...@sqlite.org - Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Long long int constants in sources
Max Vlasov wrote: > bcc 5.5 compiler ... didn't like long long constants >such as -2251799813685248LL If you want to make this particular compiler happy, use -2251799813685248i64. Regards, Clemens ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Long long int constants in sources
On Tue, 24 Dec 2019 at 23:58, Warren Young wrote: > On Dec 24, 2019, at 12:32 PM, Max Vlasov wrote: > > > > I didn't mention it was for sqlite > > static compiling with Delphi 32 bit, that supports (also quite old) OMF > > static libraries format > > Would it be out of the question to compile SQLite to a DLL? Then you can > use any Windows C compiler. You might even be able to start using the > pre-built DLL shipped from sqlite.org. > > Absolutely. I even had a dll coming along the obj binary and sometimes used it in a program instead of static one. I might as well completely migrate to dynamic linking. I just wonder how long sqlite made do without requiring 64-bit integer arithmetic from the compiler/cpu and mostly still does. ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Long long int constants in sources
On Dec 24, 2019, at 12:32 PM, Max Vlasov wrote: > > I didn't mention it was for sqlite > static compiling with Delphi 32 bit, that supports (also quite old) OMF > static libraries format Would it be out of the question to compile SQLite to a DLL? Then you can use any Windows C compiler. You might even be able to start using the pre-built DLL shipped from sqlite.org. I sorta get the charm of shipping around a single executable, but we invented dynamic linkage decades ago for several good reasons. Separate compilation and linkage by disparate toolchains is one of those reasons. ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Crash bug in sqlite
On 12/24/19, Yongheng Chen wrote: > Hi, > > We found a crash bug in sqlite. Introduced yesterday afternoon by check-in https://sqlite.org/src/info/eb95dac7f6482c36 -- D. Richard Hipp d...@sqlite.org ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] Crash bug in sqlite
Hi, We found a crash bug in sqlite. Here’s the PoC: — CREATE TABLE v0 ( v1 INTEGER PRIMARY KEY ) ; INSERT INTO v0 ( v1 ) VALUES ( 0 ) ,( 1 ) ,( 10 ) ON CONFLICT DO NOTHING ; CREATE VIRTUAL TABLE v2 USING rtree ( v5 UNIQUE ON CONFLICT ABORT , v4 , v3 ) ; SELECT 'MED BOX' - 'a' FROM v0 LEFT JOIN v2 ON v4 = 10 OR v5 = 10 ; SELECT * FROM v0 , v0 WHERE v1 = v1 AND v1 = 1; — The bug exists in the latest development code. Yongheng & Rui ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Long long int constants in sources
On Tue, 24 Dec 2019 at 21:37, Warren Young wrote: > On Dec 24, 2019, at 3:19 AM, Max Vlasov wrote: > > > > an "ancient" bcc 5.5 compiler > > Yes, [almost 20 years old][1] now. Even in these times of slowing > technology, that’s still a very long time in computing. > > ... > > If you need a free C compiler for Windows, you have many other options > these days. Philosophically, I suspect you’ll be happiest with MinGW, but > there are [many alternatives][3]. (Some of those listed don’t run on > Windows, but most do.) > > > Thanks for thoughts and suggestions. I didn't mention it was for sqlite static compiling with Delphi 32 bit, that supports (also quite old) OMF static libraries format, most of existing supports either COFF or ELF If I recall correctly. I'm in process of managing the task with with an upgraded embarcadero command-line compiler (clang based). It will probably solve my problem. ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Performance vs. memory trade-off question
I'd lean towards speed being preferable in the default. Reasoning: * People who use SQLite in low-RAM (i.e. embedded) scenarios compile it themselves. * People who use it on PCs (like me) almost never compile it, they just use whatever the distro/sqlite.org/language-of-choice provides, and that in turn uses the default. The default therefore is much more likely to affect the later user than the former. 74kB of RAM on a machine that has some multiple of ~4,000,000kB of RAM is a rounding error. Add a note to the docs page about "low RAM use notes" for those who need to know (I'm guessing there is such a page; never looked for it). My 2p, Jonathan On 2019-12-14 13:27, Richard Hipp wrote: A new feature on a branch has the following disadvantages: (1) It uses about 0.25% more CPU cycles. (Each release of SQLite is normally about 0.5% faster, so enabling this feature is sort of like going back by one-half of a release cycle.) (2) The code space (the size of the library) is between 400 and 500 bytes larger (depending on compiler and optimization settings). The this one advantage: (3) Each database connection uses about 72 KB less heap space. QUESTION: Should this feature be default-on or default-off? What's more important to you? 0.25% fewer CPU cycles or about 72KB less heap space used per database connection? The feature can be activated or deactivated at start-time, but you take the disadvantages (the performance hit and slightly larger library size) regardless, unless you disable the feature at compile-time. If the feature is compile-time disabled, then the corresponding code is omitted and and it cannot be turned on at start-time. If you have opinions, you can reply to this mailing list, or directly to me. ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Long long int constants in sources
On Dec 24, 2019, at 3:19 AM, Max Vlasov wrote: > > an "ancient" bcc 5.5 compiler Yes, [almost 20 years old][1] now. Even in these times of slowing technology, that’s still a very long time in computing. To put things into perspective, that compiler is about as old as SQLite itself! It’s a wonder it’s worked as long as it has for you. > starting 3.29.00 it appears it didn't like long long constants > such as -2251799813685248LL The “LL” syntax is [a C99 feature][2], which would have been very new at the time that compiler was released. Considering that Borland C++ was well on its way to the margins of the PC software development world by the time of that release — thus the free come-on — it doesn’t surprise me that the compiler doesn’t support that particular feature of C99. Also consider that 64-bit CPUs were still in the future in the Intel x86 world. The AMD64 architecture in the first Opteron didn’t come out until 2003, and Intel didn’t release their first processor copying the architecture until the next year. That’s not to say that 32-bit compilers — such as bcc 5.5 — didn’t support 64-bit ints, but that all of this together explains why it would have been unusual to have first-class support for them at the time. There are a bunch of other things that compiler simply won’t do. It’ll choke on a whole lot of C++ template code, for one example. The MySQL++ library that I maintain has a macro-based feature that will reliably knock it over, for another. If you need a free C compiler for Windows, you have many other options these days. Philosophically, I suspect you’ll be happiest with MinGW, but there are [many alternatives][3]. (Some of those listed don’t run on Windows, but most do.) One not on that list that should be is [Visual Studio Community Edition][4], which as of 4 or 5 years ago now is as unrestricted as the old “Professional” editions, which now exist only to serve niche cases such as those still tied to MFC and AFX. [1]: https://en.wikipedia.org/wiki/Borland_C%2B%2B#Borland_C++_Compiler [2]: https://en.cppreference.com/w/c/language/integer_constant#The_type_of_the_integer_constant [3]: https://www.thoughtco.com/list-of-free-c-compilers-958190 [4]: https://visualstudio.microsoft.com/ ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Heap Out of Bound Read in Sqlite
Yongheng Chen wrote: > This seems a problem of gcc(Ubuntu 5.5.0-12ubuntu5~16.04). When > I use this specific version to compile sqlite, the problem can be repro. Unlikely to be a compiler issue. I can reproduce the bug with valgrind with SQLite shell built with: * gcc (Ubuntu 7.4.0-1ubuntu1~18.04.1) 7.4.0 * or clang-6.0.0-1ubuntu2 Dominique ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Heap Out of Bound Read in Sqlite
On Tue, Dec 24, 2019 at 5:48 PM Richard Hipp wrote:
>
> On 12/24/19, Yongheng Chen wrote:
> >
> > When we run it with sqlite compiled with asan, we got a heap overflow crash.
> >
> > The bug exists in the latest development code.
>
> Unable to repro. Tried tip of trunk and release, using gcc and clang,
> all with various combinations of -fsanitize=memory,
> -fsanitize=address, -fsanitize=undefined, and running under valgrind.
Hi
I just tried the latest from trunk in fossil
(1c0a05b09 2019-12-24 16:20:05 UTC) and I can
reproduce the bug when running with valgrind:
$ valgrind ./sqlite3
==6674== Memcheck, a memory error detector
==6674== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==6674== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==6674== Command: ./sqlite3
==6674==
SQLite version 3.31.0 2019-12-24 16:20:05
Enter ".help" for usage hints.
Connected to a transient in-memory database.
Use ".open FILENAME" to reopen on a persistent database.
sqlite> CREATE TABLE v0 ( v2 NOT NULL PRIMARY KEY , v1 ) ;
sqlite> CREATE TEMP TRIGGER y AFTER INSERT ON v0 BEGIN DELETE FROM v0 ; END ;
sqlite> CREATE TRIGGER x DELETE ON v0 BEGIN INSERT INTO v0 ( v2 )
VALUES ( 10.1 ) ,( '' ) ,('') ,( 1) ,( 1) ,( 1) ,( 1 ) ON CONFLICT DO
NOTHING ; END ;
sqlite> INSERT INTO v0 VALUES ( 10 , 10 ) ;
sqlite> INSERT INTO v0 VALUES ( 10 , 10 ) ;
sqlite> INSERT INTO v0 VALUES ( 10 , 10 ) ;
sqlite> SELECT v2 + zipfile ( v2 , v1 + v2 ) == '1' , quote ( v1 LIKE
'1' ) FROM v0 ;
==6674== Invalid read of size 1
==6674==at 0x12944E: zipfileStep (shell.c:6243)
==6674==by 0x1B8711: sqlite3VdbeExec (sqlite3.c:91052)
==6674==by 0x1BD58F: sqlite3Step (sqlite3.c:82703)
==6674==by 0x1BD58F: sqlite3_step (sqlite3.c:82768)
==6674==by 0x13161D: exec_prepared_stmt (shell.c:11379)
==6674==by 0x13161D: shell_exec (shell.c:11684)
==6674==by 0x132C7B: runOneSqlLine (shell.c:18265)
==6674==by 0x13CCE4: process_input (shell.c:18365)
==6674==by 0x11DD65: main (shell.c:19123)
==6674== Address 0x5d15ccf is 1 bytes before a block of size 120,000 alloc'd
==6674==at 0x4C2FB0F: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6674==by 0x16AAF0: sqlite3MemMalloc (sqlite3.c:23180)
==6674==by 0x1459E1: mallocWithAlarm (sqlite3.c:27071)
==6674==by 0x1459E1: sqlite3Malloc (sqlite3.c:27101)
==6674==by 0x1516A4: setupLookaside (sqlite3.c:158620)
==6674==by 0x1E463D: openDatabase (sqlite3.c:161240)
==6674==by 0x1327FF: open_db.part.64 (shell.c:12696)
==6674==by 0x132EA6: open_db (stdio2.h:97)
==6674==by 0x132EA6: runOneSqlLine (shell.c:18261)
==6674==by 0x13CCE4: process_input (shell.c:18365)
==6674==by 0x11DD65: main (shell.c:19123)
==6674==
0|NULL
sqlite>
Line where overflow is detected in shell.c:6243:
6242 }else{
!6243 if( zName[nName-1]!='/' ){
6244 zName = zFree = sqlite3_mprintf("%s/", zName);
Regards
Dominique
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Heap Out of Bound Read in Sqlite
This seems a problem of gcc(Ubuntu 5.5.0-12ubuntu5~16.04). When I use this
specific version to compile sqlite, the problem can be repro.
Just in case you need it, here’s the log I got:
—
SQLite version 3.31.0 2019-12-24 15:35:53
Enter ".help" for usage hints.
Connected to a transient in-memory database.
Use ".open FILENAME" to reopen on a persistent database.
sqlite> CREATE TABLE v0 ( v2 NOT NULL PRIMARY KEY , v1 ) ;
sqlite> CREATE TEMP TRIGGER y AFTER INSERT ON v0 BEGIN DELETE FROM v0 ; END ;
sqlite> CREATE TRIGGER x DELETE ON v0 BEGIN INSERT INTO v0 ( v2 ) VALUES ( 10.1
) ,( '' ) ,('') ,( 1) ,( 1) ,( 1) ,( 1 ) ON CONFLICT DO NOTHING ; END ;
sqlite> INSERT INTO v0 VALUES ( 10 , 10 ) ;
sqlite> INSERT INTO v0 VALUES ( 10 , 10 ) ;
sqlite> INSERT INTO v0 VALUES ( 10 , 10 ) ;
sqlite> SELECT v2 + zipfile ( v2 , v1 + v2 ) == '1' , quote ( v1 LIKE '1' )
FROM v0 ;
=
==25839==ERROR: AddressSanitizer: heap-buffer-overflow on address
0x634007ff at pc 0x0042c622 bp 0x7ffe62feaf20 sp 0x7ffe62feaf10
READ of size 1 at 0x634007ff thread T0
#0 0x42c621 in zipfileStep /data/xxx/sqlite/asan/shell.c:6243
#1 0x5a30f6 in sqlite3VdbeExec /data/xxx/sqlite/asan/sqlite3.c:91052
#2 0x5c155e in sqlite3Step /data/xxx/sqlite/asan/sqlite3.c:82703
#3 0x5c155e in sqlite3_step /data/xxx/sqlite/asan/sqlite3.c:82768
#4 0x436e0d in exec_prepared_stmt /data/xxx/sqlite/asan/shell.c:11379
#5 0x43da53 in shell_exec /data/xxx/sqlite/asan/shell.c:11684
#6 0x440631 in runOneSqlLine /data/xxx/sqlite/asan/shell.c:18265
#7 0x450f95 in process_input /data/xxx/sqlite/asan/shell.c:18365
#8 0x412a65 in main /data/xxx/sqlite/asan/shell.c:19123
#9 0x7fc3b2a9d82f in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
#10 0x413e18 in _start (/data/xxx/sqlite/asan/sqlite3+0x413e18)
0x634007ff is located 1 bytes to the left of 12-byte region
[0x63400800,0x6341dcc0)
allocated by thread T0 here:
#0 0x7fc3b3754662 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x98662)
#1 0x4d2ea0 in sqlite3MemMalloc /data/xxx/sqlite/asan/sqlite3.c:23180
—
Yongheng Chen
> On Dec 24, 2019, at 11:48 AM, Richard Hipp wrote:
>
> On 12/24/19, Yongheng Chen wrote:
>>
>> When we run it with sqlite compiled with asan, we got a heap overflow crash.
>>
>> The bug exists in the latest development code.
>
> Unable to repro. Tried tip of trunk and release, using gcc and clang,
> all with various combinations of -fsanitize=memory,
> -fsanitize=address, -fsanitize=undefined, and running under valgrind.
>
>
> --
> D. Richard Hipp
> d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Heap Out of Bound Read in Sqlite
On 12/24/19, Yongheng Chen wrote: > > When we run it with sqlite compiled with asan, we got a heap overflow crash. > > The bug exists in the latest development code. Unable to repro. Tried tip of trunk and release, using gcc and clang, all with various combinations of -fsanitize=memory, -fsanitize=address, -fsanitize=undefined, and running under valgrind. -- D. Richard Hipp d...@sqlite.org ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] CVE's opened on 3.30.1 status
On 12/24/19, Raitses, Alex wrote: > Hi, > Can you please update on status of the following CVE’s submitted on 3.30.1? > CVE’s link to patches references GitHub branch, however I could find > corresponding submits to Fossil repository. > CVE’s list: > https://nvd.nist.gov/vuln/detail/CVE-2019-19244 > https://nvd.nist.gov/vuln/detail/CVE-2019-19603 > https://nvd.nist.gov/vuln/detail/CVE-2019-19242 > https://nvd.nist.gov/vuln/detail/CVE-2019-19646 > https://nvd.nist.gov/vuln/detail/CVE-2019-19645 None of these CVEs describe actual vulnerabilities, at least not for the typical use-case for SQLite. If you have an unusual application in which you allow unauthenticated users to submit arbitrary SQL to your application, then four of these CVEs describe a denial-of-service opportunity to an attacker. In other words, an attacker who can present arbitrary SQL queries (and DDL statements) to the application can cause the application to crash. Not many applications fall into that category, though. The only application that I know of that does this is the Chrome web-browser. How does your application use SQLite? Do you allow anonymous attackers to present arbitrary SQL to your application? If not, then none of this applies to you. The CVE-2019-19646 describes a bug in a new feature of SQLite that has not yet been released. CVE-2019-19646 was apparently submitted in error. Unfortunately, we do not know of any mechanism to correct erroneous CVEs. Do you? All of the problems described by the CVEs you list have been fixed. In fact, most of the CVEs you list point to the check-in that fixes the problem, in a GitHub mirror of the SQLite repository. The SQLite developers do not issue or track CVEs. CVEs against SQLite are issued by third-parties, typically third-parties who are running fuzzers against the SQLite, and usually without the consultation or approval of the SQLite developers. -- D. Richard Hipp d...@sqlite.org ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] Heap Out of Bound Read in Sqlite
Hi,
We found a oob read in sqlite. Here’s the PoC:
—
CREATE TABLE v0 ( v2 NOT NULL PRIMARY KEY , v1 ) ;
CREATE TEMP TRIGGER y AFTER INSERT ON v0 BEGIN DELETE FROM v0 ; END ;
CREATE TRIGGER x DELETE ON v0 BEGIN INSERT INTO v0 ( v2 ) VALUES ( 10.1 ) ,( ''
) ,('') ,( 1) ,( 1) ,( 1) ,( 1 ) ON CONFLICT DO NOTHING ; END ;
INSERT INTO v0 VALUES ( 10 , 10 ) ;
INSERT INTO v0 VALUES ( 10 , 10 ) ;
INSERT INTO v0 VALUES ( 10 , 10 ) ;
SELECT v2 + zipfile ( v2 , v1 + v2 ) == '1' , quote ( v1 LIKE '1' ) FROM v0 ;
—
When we run it with sqlite compiled with asan, we got a heap overflow crash.
The bug exists in the latest development code.
Yongheng & Rui
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] CVE's opened on 3.30.1 status
Hi, Can you please update on status of the following CVE’s submitted on 3.30.1? CVE’s link to patches references GitHub branch, however I could find corresponding submits to Fossil repository. CVE’s list: https://nvd.nist.gov/vuln/detail/CVE-2019-19244 https://nvd.nist.gov/vuln/detail/CVE-2019-19603 https://nvd.nist.gov/vuln/detail/CVE-2019-19242 https://nvd.nist.gov/vuln/detail/CVE-2019-19646 https://nvd.nist.gov/vuln/detail/CVE-2019-19645 Regards, Alex - Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] No such column
In a specific case, we have to use such a scenario. I'm aware it is contrary to traditional way, but for this specific "mounted drive" situation, is there a reasonable solution? Any way to avoid this kind of database file corruption? Thanks in advance, Best Regards, On Tue, Dec 24, 2019 at 12:45 PM Darren Duncan wrote: > On 2019-12-22 10:48 p.m., Keith Medcalf wrote: > > On Sunday, 22 December, 2019 23:20, Aydin Ozgur Yagmur < > ayagmu...@gmail.com> wrote: > >> I have experienced a weird problem. I have been using sqlite database in > >> linux by mounting. > > > > Can you give some clues what "using sqlite database in linux by > mounting" means? > > My first thought on reading that was that "mounting" meant using the > ATTACH > command, since in the analogy of the SQL environment as a filesystem, > using > ATTACH is like mounting a volume within the filesystem in order to access > the > volume's contents, which are tables. -- Darren Duncan > ___ > sqlite-users mailing list > sqlite-users@mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] Long long int constants in sources
Hi, an "ancient" bcc 5.5 compiler perfectly compiled sqlite to win32 until 3.28.00, but starting 3.29.00 it appears it didn't like long long constants such as -2251799813685248LL , mentioned at least in sqlite3RealSameAsInt and sqlite3VdbeExec. The errors tells unrelated error messages, like [ ) expected in function ] or [ If statement missing ) ], but in all those cases the lines contained long long constants. Is this something that appeared unintentionally and might be fixed or long long int constants are first-class citizens now? Thanks, Max ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] No such column
On 2019-12-22 10:48 p.m., Keith Medcalf wrote: On Sunday, 22 December, 2019 23:20, Aydin Ozgur Yagmur wrote: I have experienced a weird problem. I have been using sqlite database in linux by mounting. Can you give some clues what "using sqlite database in linux by mounting" means? My first thought on reading that was that "mounting" meant using the ATTACH command, since in the analogy of the SQL environment as a filesystem, using ATTACH is like mounting a volume within the filesystem in order to access the volume's contents, which are tables. -- Darren Duncan ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
