[sqlite] keep out focus
Dear sirs: I want to appology for this message. Initially I want to send to the Lazarus List, but if anyone has the solution, I will appreciate very much Thanks Yours Ing. H?ctor F. Fiandor Rosario
[sqlite] Article about pointer abuse in SQLite
On Wed, 23 Mar 2016 12:59 am Adam Devita wrote: > > This discussion on the nature of undefined behaviour code is > interesting. I don't know the reasoning, but it seems that VS6 often > initialized things to 0xcd in debug mode and (usually) had memory > uninitialized to 0x00 when complied in Release (perhaps 0x00 just > happens to be what was on the stack or heap). I presume this wasn't > just to make people suffer when things don't work the same in debug > vs release mode. > It's not uncommon for compilers to initialise variables to definitely bad values in debug mode to help find these kinds of bugs. However if you were getting 00s in VC++ you were getting lucky and would probably continue to get lucky until an unexpected stack allocation changed the usual location, after which all bets are off (speaking from VC++ experience and VC++6 specifically). >
[sqlite] Article about pointer abuse in SQLite
On Tue, 22 Mar 2016 11:00:24 -0500 "Marc L. Allen" wrote: > I don't think compilers "run" your code. Provided we're talking about a C compiler, you're right. Optimizers don't run the code, they reason about it. > The fact that the code never actually allows that path to occur is > beyond the scope of most compilers, isn't it? Yes and no. If the compiler can prove a particular branch can never be taken, it can remove it because the logic of the program will not be affected. If it cannot prove that, the code will remain. For example, given int foo = 0; if (foo) exit(0); the compiler can delete lines 2 & 3. If there's no other reference to foo, it can delete line 1, too. However, extern int foo; if (foo) exit(0); and int foo = 0; extern int *pfoo; pfoo = &foo; if (foo) exit(0); both leave most optimzers flat-footed. The potential for another module to affect the value of foo means the code could run, and thus must remain. --jkl
[sqlite] Article about pointer abuse in SQLite
On Tue, 22 Mar 2016 09:58:52 -0400 Adam Devita wrote: > I don't know the reasoning, but it seems that VS6 often > initialized things to 0xcd in debug mode and (usually) had memory > uninitialized to 0x00 when complied in Release (perhaps 0x00 just > happens to be what was on the stack or heap). I would be talking out of school here if you're talking about C#. For C and C++, the 0xcd initialization helps make (mis)use of uninitalized objects more obvious. If the allocated buffer happens to be zero-initialized, things like printf will make them appear empty when they're actually invalid. This link has a nice discussion: http://stackoverflow.com/questions/2769247/controling-crt-memory-initialization and includes a link to the documented behavior: https://msdn.microsoft.com/en-us/library/Aa270812 --jkl
[sqlite] Article about pointer abuse in SQLite
On Tue, 22 Mar 2016 09:56:57 +0100 "Cezary H. Noweta" wrote: > On 2016-03-22 00:35, James K. Lowden wrote: > >[...] An example from Clang's discussion is > > > > int i = 10 << 31; > > Could you provide a link for that discussion? (Or google's phrase to > retrieve such link?) I'm sorry, no. Not for the first time I wish my browser had a feature like "find links in history with documents matching regex". I didn't read it on the Clang mailing list. I think I saw it by reference in Regehr's discussion of "friendly C". It specifically mentioned 10 << 31 as an example of an "integer" requiring 35 bits, something gcc assigns silently and clang diagnoses with a warning. If you haven't seen it, http://blog.regehr.org/archives/1180 is a good starting point. It mentions "Towards Optimization-Safe Systems: Analyzing the Impact of Undefined Behavior" (http://pdos.csail.mit.edu/papers/stack:sosp13.pdf), which is where I learned that sharp-edged optimization is not a brand-new phenomenon. DJB provides a properly justified grumpy, frustrated view, https://groups.google.com/forum/m/#!msg/boring-crypto/48qa1kWignU/o8GGp2K1DAAJ wherein he mentions one of the defenses for the status quo, "that a boring C compiler can't possibly support the desired system _performance_. Even if this were true (which I very much doubt), why would it be more important than system _correctness_?" That should be the only argument needed. DJB is concerned about security. DRH is concerned about correctness. The serious C programmer doesn't breath who prizes performance over correctness, yet that is the license the compiler writers have granted themselves. --jkl
[sqlite] Article about pointer abuse in SQLite
> This discussion on the nature of undefined behaviour code is > interesting. I don't know the reasoning, but it seems that VS6 often > initialized things to 0xcd in debug mode and (usually) had memory > uninitialized to 0x00 when complied in Release (perhaps 0x00 just > happens to be what was on the stack or heap). I presume this wasn't > just to make people suffer when things don't work the same in debug > vs release mode. The initialization of memory to non-0x00 is a compiler function. For obvious security reasons all allocations from the Operating System are pre-initialized to 0x00. This is so that your program cannot request a big hunk of virtual memory which is full of a predecessor process data and then proceed to search it for nifty things like previously used private keys, userids, passwords, and so forth. Such behaviour is required for any Operating Systems to obtain any security certification level whatsoever.
[sqlite] FTS5 "constraint failed"
Hello !
It's a sqlite repository clone that follows trunk.
SQLite version 3.12.0 2016-03-22 15:26:03
Enter ".help" for usage hints
Connected to a transient in-memory database.
Use ".open FILENAME" to reopen on a persistent database.
Cheers !
?
> Tue Mar 22 2016 06:23:53 PM CET from "Dan Kennedy"
> Subject: Re: [sqlite] FTS5 "constraint failed"
>
> On 03/23/2016 12:06 AM, Domingo Alvarez Duarte wrote:
>
>>Hello !
>>
>> After seeing several times work/commits on fts5 I decided to try it on a
>> table shown bellow, and when trying to populate it I get this error
>>message:
>>
>>
>> sqlite> INSERT INTO fts_idx_items(fts_idx_items) VALUES('rebuild');
>> Error: constraint failed
>>
>> The table has 12,000,000 records and it show the error message after 10
>> seconds working, any clue on what can be happening ?
>>
> Thanks for testing this. What does "SELECT sqlite_version();" return if
> you run it in the same shell?
>
> Thanks,
> Dan.
>
> ___
> sqlite-users mailing list
> sqlite-users at mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
>
>
?
[sqlite] FTS5 "constraint failed"
In this case sqlite is compiled with the following flags:
gcc -g -O2 -DSQLITE_OS_UNIX=1 -I. -I/third-party/sqlite3/src
-I/third-party/sqlite3/ext/rtree -I/third-party/sqlite3/ext/fts3
-D_HAVE_SQLITE_CONFIG_H -DBUILD_sqlite -DSQLITE_HAS_CODEC=1
-DSQLITE_ENABLE_FTS4=1 -DSQLITE_ENABLE_FTS3 -DSQLITE_ENABLE_RTREE=1
-DSQLITE_ENABLE_COLUMN_METADATA=1 -DSQLITE_ENABLE_FTS3_PARENTHESIS=1
-DSQLITE_DEFAULT_FOREIGN_KEYS=1 -DSQLITE_USE_URI=1
-DSQLITE_ENABLE_UNLOCK_NOTIFY=1 -DSQLITE_USE_DECIMAL2=1
-DSQLITE_ENABLE_STAT4=1 -DCODEC_TYPE=CODEC_TYPE_AES2562 -DSQLITE_SOUNDEX=1
-DSQLITE_ENABLE_EXTENSION_FUNCTIONS=1 -DSQLITE_OMIT_PREPARED=1 -DNDEBUG
-DSQLITE_THREADSAFE=1 -DSQLITE_ENABLE_FTS5 -DSQLITE_ENABLE_JSON1?
-DSQLITE_SMALL_STACK=1 -DHAVE_READLINE=0 -DHAVE_EDITLINE=1
-DSQLITE_ENABLE_JSON1 -DSQLITE_ENABLE_FTS4 -DSQLITE_ENABLE_EXPLAIN_COMMENTS
-o sqlite3 /third-party/sqlite3/src/shell.c sqlite3.c? -ledit -ldl -lpthread
-lm -Wl,-rpath -Wl,/usr/local/lib
?
> Tue Mar 22 2016 06:06:55 PM CET from "Domingo Alvarez Duarte"
> Subject: [sqlite] FTS5 "constraint failed"
>
> Hello !
>
> After seeing several times work/commits on fts5 I decided to try it on a
> table shown bellow, and when trying to populate it I get this error
>message:
>
>
> sqlite> INSERT INTO fts_idx_items(fts_idx_items) VALUES('rebuild');
> Error: constraint failed
>
> The table has 12,000,000 records and it show the error message after 10
> seconds working, any clue on what can be happening ?
>
> Cheers !
>
> CREATE TABLE "items" (
> ??? 'id' integer PRIMARY KEY,
> ??? 'parent' INTEGER,
> ??? 'by' text COLLATE NOCASE,
> ??? 'score' integer DEFAULT 0,
> ??? 'title' text? COLLATE NOCASE,
> ??? 'type' text? COLLATE NOCASE,
> ??? 'url' text? COLLATE NOCASE,
> ??? 'deleted' BOOLEAN DEFAULT 0,
> ??? 'dead' BOOLEAN DEFAULT 0,
> ??? 'comment' TEXT COLLATE NOCASE,
> ??? 'time' integer NOT NULL,
> ??? descendants integer default 0
> );
>
> CREATE VIRTUAL TABLE fts_idx_items USING fts5(title, comment,
>content=items,
> content_rowid=id);
>
> INSERT INTO fts_idx_items(fts_idx_items) VALUES('rebuild');
>
> ___
> sqlite-users mailing list
> sqlite-users at mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
>
>
?
[sqlite] FTS5 "constraint failed"
Hello !
After seeing several times work/commits on fts5 I decided to try it on a
table shown bellow, and when trying to populate it I get this error message:
sqlite> INSERT INTO fts_idx_items(fts_idx_items) VALUES('rebuild');
Error: constraint failed
The table has 12,000,000 records and it show the error message after 10
seconds working, any clue on what can be happening ?
Cheers !
CREATE TABLE "items" (
??? 'id' integer PRIMARY KEY,
??? 'parent' INTEGER,
??? 'by' text COLLATE NOCASE,
??? 'score' integer DEFAULT 0,
??? 'title' text? COLLATE NOCASE,
??? 'type' text? COLLATE NOCASE,
??? 'url' text? COLLATE NOCASE,
??? 'deleted' BOOLEAN DEFAULT 0,
??? 'dead' BOOLEAN DEFAULT 0,
??? 'comment' TEXT COLLATE NOCASE,
??? 'time' integer NOT NULL,
??? descendants integer default 0
);
CREATE VIRTUAL TABLE fts_idx_items USING fts5(title, comment, content=items,
content_rowid=id);
INSERT INTO fts_idx_items(fts_idx_items) VALUES('rebuild');
[sqlite] Version 3.12.0 coming soon
On 22 Mar 2016, at 4:42pm, Richard Hipp wrote: > A preview of the change log can be seen at > https://www.sqlite.org/draft/releaselog/3_12_0.html " ? The query planner considers the LIMIT clause when estimating the cost or ORDER BY. ? The configure script (on unix) automatically detects the availablity of pread() and pwrite() and sets of compile-time options to use those OS interfaces if they are available." I presume that the first of those should read "cost of". I presume that in the second one "sets of" should be "sets". Simon.
[sqlite] sqldiff nowadays
On 2016-03-22 13:49, Richard Hipp wrote: > On 3/22/16, MM wrote: >> Hello, >> I can see sqldiff appearing here: >> >> https://www.sqlite.org/sqldiff.html >> >> and in the downloads page as part of a linux 32bit binary package. >> Alas I don't see any 64bit package. > > The 32bit binaries will run fine on 64bit machines. > >> >> Given a distro-installed 64bit sqlite binary and libs, which part of the >> sources would 1 need to download only sqldiff and build only that, in 64bit >> as well. >> > > Download the canonical source code distro and type: > > ./configure; make sqldiff > In addition to the universal advice above, if you are not only interested in getting the tool working once, but also in _future_ sustainable support and consistency delivered for you by your OS distributor, please tell us which Linux distribution you are using. Then other (more experienced) same distro users on the list eventually will be able to point you to the appropriate procedure and contacts, so the system sqlite package to be extended with sqldiff for all distro users. If, by chance, you are on something Fedora based, I could give you some hints how to help our lead maintainer - Jan Stanek with the package enhancement myself. Regards, Alek
[sqlite] sqldiff nowadays
On 22 March 2016 at 13:28, Alek Paunov wrote: > On 2016-03-22 13:49, Richard Hipp wrote: > >> On 3/22/16, MM wrote: >> >>> Hello, >>> I can see sqldiff appearing here: >>> >>> https://www.sqlite.org/sqldiff.html >>> >>> and in the downloads page as part of a linux 32bit binary package. >>> Alas I don't see any 64bit package. >>> >> >> The 32bit binaries will run fine on 64bit machines. >> >> >>> Given a distro-installed 64bit sqlite binary and libs, which part of the >>> sources would 1 need to download only sqldiff and build only that, in >>> 64bit >>> as well. >>> >>> >> Download the canonical source code distro and type: >> >> ./configure; make sqldiff >> >> > In addition to the universal advice above, if you are not only interested > in getting the tool working once, but also in _future_ sustainable support > and consistency delivered for you by your OS distributor, please tell us > which Linux distribution you are using. > > Then other (more experienced) same distro users on the list eventually > will be able to point you to the appropriate procedure and contacts, so the > system sqlite package to be extended with sqldiff for all distro users. > > If, by chance, you are on something Fedora based, I could give you some > hints how to help our lead maintainer - Jan Stanek with the package > enhancement myself. > > Regards, > Alek > > Indeed, I am using fedora 23. I have the following rpms installed (though we are getting a bit out of scope for this list I suppose): sqlite-libs-3.11.0-3.fc23.x86_64 sqlite-3.11.0-3.fc23.x86_64 sqlite-analyzer-3.11.0-3.fc23.x86_64 sqlite-doc-3.11.0-3.fc23.noarch sqlite-devel-3.11.0-3.fc23.x86_64 none of them has sqldiff. thanks MM
[sqlite] sqldiff nowadays
On 22/03/16 11:49, Richard Hipp wrote: > On 3/22/16, MM wrote: >> Hello, >> I can see sqldiff appearing here: >> >> https://www.sqlite.org/sqldiff.html >> >> and in the downloads page as part of a linux 32bit binary package. >> Alas I don't see any 64bit package. > > The 32bit binaries will run fine on 64bit machines. That's not true for some GNU/Linux distributions which do not include the necessary libraries to save disk space and make updates shorter. That is not to say that sqldiff should have such prebuilt binaries. It's safer in many respects to just compile and package it yourself. - Matthias-Christian
[sqlite] Version 3.12.0 coming soon
The status board for SQLite version 3.12.0 (https://www.sqlite.org/checklists/312/index) is now active. The release will occur when all items go green. The "Pre-Release Snapshot" over at https://www.sqlite.org/download.html contains the latest code. A preview of the change log can be seen at https://www.sqlite.org/draft/releaselog/3_12_0.html If you have any issues or concerns with the current code, you should raise them *very soon*. -- D. Richard Hipp drh at sqlite.org
[sqlite] sqldiff nowadays
Hello, I can see sqldiff appearing here: https://www.sqlite.org/sqldiff.html and in the downloads page as part of a linux 32bit binary package. Alas I don't see any 64bit package. Given a distro-installed 64bit sqlite binary and libs, which part of the sources would 1 need to download only sqldiff and build only that, in 64bit as well. Rds, MM
[sqlite] Article about pointer abuse in SQLite
I don't think compilers "run" your code. When looking for uninitialized
variables, it simply looks for a potential path through the code that uses a
variable without it being initialized.
The fact that the code never actually allows that path to occur is beyond the
scope of most compilers, isn't it?
-Original Message-
From: sqlite-users-bounces at mailinglists.sqlite.org
[mailto:sqlite-users-boun...@mailinglists.sqlite.org] On Behalf Of J Decker
Sent: Tuesday, March 22, 2016 11:43 AM
To: SQLite mailing list
Subject: Re: [sqlite] Article about pointer abuse in SQLite
On Tue, Mar 22, 2016 at 6:58 AM, Adam Devita wrote:
> It may be pedantic, but VS2016 will stop complaining if you edit your
> definition of s to large_struct s=new large_struct(); //set s to an
> actual instance of large_struct. c people can think of s as a pointer,
> and in c# the members are set to their default values.
>
The point was, the structure had some 20 members, and 90% of the time the
conditions don't exist for it to be initialized. So rather than initialize it
90% of the time for no use, I added checks to optimize the object's creation.
> J Decker's point could also have been made by using int x in place of
> large_struct s . and sub x for s.x , since it is a contrived example
> anyway. The only way to use x is if another conditional on another
> variable that follows it in code and it is initialized.
>
> if one writes
> const bool arbitrary_true_false = true; //note the const as Scott
> Doctor implied, makes the error go away.
>
It's not a const though, it's a variable the changes during runtime and allows
for the creation of such an object. It's not 'contrived' it was an example that
I ran into while developing (several times in fact).
similarly soemthing like (I haven't run it though compilers, so don't know if
this is nested enough to cause the same issue... but it's easy to see how a
compiler/error checker would similarly be confused.
void f() { int a, b;
for( a = 0; a < 2; a++ ) {
if( a == 0 ) b = 1234;
}
printf( "b is never uniniialized here : %d", b ); }
> -
> This discussion on the nature of undefined behaviour code is
> interesting. I don't know the reasoning, but it seems that VS6 often
> initialized things to 0xcd in debug mode and (usually) had memory
> uninitialized to 0x00 when complied in Release (perhaps 0x00 just
> happens to be what was on the stack or heap). I presume this wasn't
> just to make people suffer when things don't work the same in debug
> vs release mode.
>
> Does the tool help (in the sqlite in practice) point out things that
> could be problematic? Is it a compiler's variant of "hay, you are
> depending on implemented, not documented behaviour" ?
>
> regards,
> Adam DeVita
>
>
> On Tue, Mar 22, 2016 at 7:27 AM, Scott Doctor
> wrote:
>>
>> It is uninitialized. you are setting an initial value within an if
>> statement. For the compiler, the code has NOT actually executed. so
>> it does not use the value of the variable arbitrary_true_false. If it
>> was a #define then it would use the value but still give an error
>> because it is not a compiler directive #if but a code if.
>>
>> The logic is that the first instance of assignment is within a conditional.
>> That is a particularly nasty kind of bug and should be reported as an error.
>> because if later you decide to change arbitrary_true_false to false,
>> then s.x would not be initialized before use. the compiler is correct
>> to issue the warning. Give s.x a value after/at initialization, but
>> before the if statement to give it a desired initial value then
>> recompile, that should fix the error.
>>
>> Compilers only set the code to initialize the variable at
>> declaration, not actually use the values during compile. If it was
>> declared as a constant using a compiler directive such as #define,
>> then the compiler would use the value in the logic and still give an
>> error, but a different one because the conditional would always
>> evaluate true (or false depending on what it was set to)
>>
>>
>> On 03/21/2016 21:31, J Decker wrote:
>>>
>>> On Mon, Mar 21, 2016 at 8:40 PM, Scott Doctor
>>>
>>> wrote:
you are missing
using System;
>>>
>>> whatever. It still fails because it says the variable is
>>> uninitilalized. THe only thing that doesn't is actually running it.
>>>
>>> That same pattern not matter what the language triggers
>>> warning/error checkers
Scott Doctor
scott at scottdoctor.com
--
On 3/21/2016 5:21 PM, J Decker wrote:
>
> So far I just see analysis tools fail for the same sorts of valid
> code...
>
> this is a bit of C# but the same idea causes the same warnings and
> there's nothign tecniclally wrong with this.
>
>
>
> class test
> {
> struct large_struct { public int x; }
> boo
[sqlite] Article about pointer abuse in SQLite
It may be pedantic, but VS2016 will stop complaining if you edit your
definition of s to
large_struct s=new large_struct(); //set s to an actual instance of
large_struct. c people can think of s as a pointer, and in c# the
members are set to their default values.
J Decker's point could also have been made by using int x in place of
large_struct s . and sub x for s.x , since it is a contrived example
anyway. The only way to use x is if another conditional on another
variable that follows it in code and it is initialized.
if one writes
const bool arbitrary_true_false = true; //note the const as Scott
Doctor implied, makes the error go away.
-
This discussion on the nature of undefined behaviour code is
interesting. I don't know the reasoning, but it seems that VS6 often
initialized things to 0xcd in debug mode and (usually) had memory
uninitialized to 0x00 when complied in Release (perhaps 0x00 just
happens to be what was on the stack or heap). I presume this wasn't
just to make people suffer when things don't work the same in debug
vs release mode.
Does the tool help (in the sqlite in practice) point out things that
could be problematic? Is it a compiler's variant of "hay, you are
depending on implemented, not documented behaviour" ?
regards,
Adam DeVita
On Tue, Mar 22, 2016 at 7:27 AM, Scott Doctor wrote:
>
> It is uninitialized. you are setting an initial value within an if
> statement. For the compiler, the code has NOT actually executed. so it does
> not use the value of the variable arbitrary_true_false. If it was a #define
> then it would use the value but still give an error because it is not a
> compiler directive #if but a code if.
>
> The logic is that the first instance of assignment is within a conditional.
> That is a particularly nasty kind of bug and should be reported as an error.
> because if later you decide to change arbitrary_true_false to false, then
> s.x would not be initialized before use. the compiler is correct to issue
> the warning. Give s.x a value after/at initialization, but before the if
> statement to give it a desired initial value then recompile, that should fix
> the error.
>
> Compilers only set the code to initialize the variable at declaration, not
> actually use the values during compile. If it was declared as a constant
> using a compiler directive such as #define, then the compiler would use the
> value in the logic and still give an error, but a different one because the
> conditional would always evaluate true (or false depending on what it was
> set to)
>
>
> On 03/21/2016 21:31, J Decker wrote:
>>
>> On Mon, Mar 21, 2016 at 8:40 PM, Scott Doctor
>> wrote:
>>>
>>> you are missing
>>>
>>> using System;
>>
>> whatever. It still fails because it says the variable is
>> uninitilalized. THe only thing that doesn't is actually running it.
>>
>> That same pattern not matter what the language triggers warning/error
>> checkers
>>>
>>>
>>> Scott Doctor
>>> scott at scottdoctor.com
>>> --
>>>
>>>
>>> On 3/21/2016 5:21 PM, J Decker wrote:
So far I just see analysis tools fail for the same sorts of valid
code...
this is a bit of C# but the same idea causes the same warnings and
there's nothign tecniclally wrong with this.
class test
{
struct large_struct { public int x; }
bool arbitrary_true_false = true;
void method()
{
bool initialized = false;
large_struct s;
if( arbitrary_true_false )
{
initialized = true;
s.x = 1;
}
if( initialized )
{
Console.WriteLine( "this fails(during compile) as
uninitialized: {0}", s.x );
}
}
}
On Mon, Mar 21, 2016 at 4:35 PM, James K. Lowden
wrote:
>
> On Mon, 21 Mar 2016 13:48:06 -0700
> Scott Perry wrote:
>
>> Compilers allow you to choose your standard; --std=c11 means
>> something very specific (and unchanging)
>
> They do. And that covers what the standard covers. The standard also
> has limits. It includes constructs that are syntactically permitted
> but whose behavior is left undefined, known by the scarred as "UB" for
> "undefined behavior". An example from Clang's discussion is
>
> int i = 10 << 31;
>
> The standard says << is a shift operator. It places no limit on the
> number of bits to be shifted. If that number is so large that the
> product cannot be represented by the assigned variable, that is *not*
> an error. The standard allows the compiler to do anything or nothing
> with it. As you may imagine, the varieties of anything and nothing are
> many.
>
> Compiler writers are well aware that "nothing" is faster done than
> "something". Over time, they have gotten more aggressive in simp
[sqlite] Article about pointer abuse in SQLite
Hello, On 2016-03-22 00:35, James K. Lowden wrote: >[...] An example from Clang's discussion is > > int i = 10 << 31; Could you provide a link for that discussion? (Or google's phrase to retrieve such link?) -- best regards Cezary H. Noweta
[sqlite] Reserved column names
On Tue, Mar 22, 2016 at 8:45 AM, Dominique Devienne wrote: > On Tue, Mar 22, 2016 at 12:36 AM, James K. Lowden < > jklowden at schemamania.org> wrote: > >> Roger's APSW is SQLIte specific. It's pretty easy to imagine, isn't >> it, that >> >> char sql[] = "select [col] from [foo]"; >> >> is easier for him to use than >> >> char sql[] = "select \"col\" from \"foo\""; >> >> even if he's not using C? >> > > Then I'd advise https://www.sqlite.org/c3ref/mprintf.html and %q or %Q :) > That's silly of course, that's for literals, not idents. Oh well... But %w to the rescue! The "%w" formatting option is intended for safely inserting table and column names into a constructed SQL statement. It escapes the double-quote character instead of the single-quote character.
[sqlite] Reserved column names
On Tue, Mar 22, 2016 at 12:36 AM, James K. Lowden wrote: > Roger's APSW is SQLIte specific. It's pretty easy to imagine, isn't > it, that > > char sql[] = "select [col] from [foo]"; > > is easier for him to use than > > char sql[] = "select \"col\" from \"foo\""; > > even if he's not using C? > Then I'd advise https://www.sqlite.org/c3ref/mprintf.html and %q or %Q :) > I would certainly advise (and often do) anyone using SQL to learn to > distinguish between standard SQL and any given product's deviations > from it. Favoring standard constructs helps avoid weird corners and style. > Exactly the reason I wanted to emphasize it's non-standard, and not good general advice IMHO. > But machine-generated code inside a driver specifically for SQLite? > Hard to see who benefits, one way or the other. To each his own of course. But just like one shouldn't use double-quotes for string literal, despite's SQLite support for them, one shouldn't use (IMHO) square-brackets for idents. --DD
[sqlite] Article about pointer abuse in SQLite
On Tue, Mar 22, 2016 at 6:58 AM, Adam Devita wrote:
> It may be pedantic, but VS2016 will stop complaining if you edit your
> definition of s to
> large_struct s=new large_struct(); //set s to an actual instance of
> large_struct. c people can think of s as a pointer, and in c# the
> members are set to their default values.
>
The point was, the structure had some 20 members, and 90% of the time
the conditions don't exist for it to be initialized. So rather than
initialize it 90% of the time for no use, I added checks to optimize
the object's creation.
> J Decker's point could also have been made by using int x in place of
> large_struct s . and sub x for s.x , since it is a contrived example
> anyway. The only way to use x is if another conditional on another
> variable that follows it in code and it is initialized.
>
> if one writes
> const bool arbitrary_true_false = true; //note the const as Scott
> Doctor implied, makes the error go away.
>
It's not a const though, it's a variable the changes during runtime
and allows for the creation of such an object. It's not 'contrived' it
was an example that I ran into while developing (several times in
fact).
similarly soemthing like (I haven't run it though compilers, so don't
know if this is nested enough to cause the same issue... but it's easy
to see how a compiler/error checker would similarly be confused.
void f() { int a, b;
for( a = 0; a < 2; a++ ) {
if( a == 0 ) b = 1234;
}
printf( "b is never uniniialized here : %d", b );
}
> -
> This discussion on the nature of undefined behaviour code is
> interesting. I don't know the reasoning, but it seems that VS6 often
> initialized things to 0xcd in debug mode and (usually) had memory
> uninitialized to 0x00 when complied in Release (perhaps 0x00 just
> happens to be what was on the stack or heap). I presume this wasn't
> just to make people suffer when things don't work the same in debug
> vs release mode.
>
> Does the tool help (in the sqlite in practice) point out things that
> could be problematic? Is it a compiler's variant of "hay, you are
> depending on implemented, not documented behaviour" ?
>
> regards,
> Adam DeVita
>
>
> On Tue, Mar 22, 2016 at 7:27 AM, Scott Doctor
> wrote:
>>
>> It is uninitialized. you are setting an initial value within an if
>> statement. For the compiler, the code has NOT actually executed. so it does
>> not use the value of the variable arbitrary_true_false. If it was a #define
>> then it would use the value but still give an error because it is not a
>> compiler directive #if but a code if.
>>
>> The logic is that the first instance of assignment is within a conditional.
>> That is a particularly nasty kind of bug and should be reported as an error.
>> because if later you decide to change arbitrary_true_false to false, then
>> s.x would not be initialized before use. the compiler is correct to issue
>> the warning. Give s.x a value after/at initialization, but before the if
>> statement to give it a desired initial value then recompile, that should fix
>> the error.
>>
>> Compilers only set the code to initialize the variable at declaration, not
>> actually use the values during compile. If it was declared as a constant
>> using a compiler directive such as #define, then the compiler would use the
>> value in the logic and still give an error, but a different one because the
>> conditional would always evaluate true (or false depending on what it was
>> set to)
>>
>>
>> On 03/21/2016 21:31, J Decker wrote:
>>>
>>> On Mon, Mar 21, 2016 at 8:40 PM, Scott Doctor
>>> wrote:
you are missing
using System;
>>>
>>> whatever. It still fails because it says the variable is
>>> uninitilalized. THe only thing that doesn't is actually running it.
>>>
>>> That same pattern not matter what the language triggers warning/error
>>> checkers
Scott Doctor
scott at scottdoctor.com
--
On 3/21/2016 5:21 PM, J Decker wrote:
>
> So far I just see analysis tools fail for the same sorts of valid
> code...
>
> this is a bit of C# but the same idea causes the same warnings and
> there's nothign tecniclally wrong with this.
>
>
>
> class test
> {
> struct large_struct { public int x; }
> bool arbitrary_true_false = true;
> void method()
> {
> bool initialized = false;
> large_struct s;
> if( arbitrary_true_false )
> {
>initialized = true;
>s.x = 1;
> }
> if( initialized )
> {
>Console.WriteLine( "this fails(during compile) as
> uninitialized: {0}", s.x );
> }
> }
> }
>
> On Mon, Mar 21, 2016 at 4:35 PM, James K. Lowden
> wrote:
>>
>> On Mon, 21 Mar 2016 13:48:06 -0700
>> Scott Perry wrote:
>>
>>> Com
[sqlite] Article about pointer abuse in SQLite
On Tue, Mar 22, 2016 at 4:27 AM, Scott Doctor wrote:
>
> It is uninitialized. you are setting an initial value within an if
> statement. For the compiler, the code has NOT actually executed. so it does
> not use the value of the variable arbitrary_true_false. If it was a #define
> then it would use the value but still give an error because it is not a
> compiler directive #if but a code if.
>
> The logic is that the first instance of assignment is within a conditional.
> That is a particularly nasty kind of bug and should be reported as an error.
> because if later you decide to change arbitrary_true_false to false, then
> s.x would not be initialized before use. the compiler is correct to issue
> the warning. Give s.x a value after/at initialization, but before the if
> statement to give it a desired initial value then recompile, that should fix
> the error.
>
> Compilers only set the code to initialize the variable at declaration, not
> actually use the values during compile. If it was declared as a constant
> using a compiler directive such as #define, then the compiler would use the
> value in the logic and still give an error, but a different one because the
> conditional would always evaluate true (or false depending on what it was
> set to)
>
The usage is never uninitinalized. You can pass false all you want,
once you make it ot passing it true, the initialized gets set, and the
thing IS initialized.
There is no cause for warning or error in either of these cases.
There is NEVER a time when it will be used and be unassigned.
See - it's too complex for even human minds to reason through how
could a dumb tool have any hope?
>
> On 03/21/2016 21:31, J Decker wrote:
>>
>> On Mon, Mar 21, 2016 at 8:40 PM, Scott Doctor
>> wrote:
>>>
>>> you are missing
>>>
>>> using System;
>>
>> whatever. It still fails because it says the variable is
>> uninitilalized. THe only thing that doesn't is actually running it.
>>
>> That same pattern not matter what the language triggers warning/error
>> checkers
>>>
>>>
>>> Scott Doctor
>>> scott at scottdoctor.com
>>> --
>>>
>>>
>>> On 3/21/2016 5:21 PM, J Decker wrote:
So far I just see analysis tools fail for the same sorts of valid
code...
this is a bit of C# but the same idea causes the same warnings and
there's nothign tecniclally wrong with this.
class test
{
struct large_struct { public int x; }
bool arbitrary_true_false = true;
void method()
{
bool initialized = false;
large_struct s;
if( arbitrary_true_false )
{
initialized = true;
s.x = 1;
}
if( initialized )
{
Console.WriteLine( "this fails(during compile) as
uninitialized: {0}", s.x );
}
}
}
On Mon, Mar 21, 2016 at 4:35 PM, James K. Lowden
wrote:
>
> On Mon, 21 Mar 2016 13:48:06 -0700
> Scott Perry wrote:
>
>> Compilers allow you to choose your standard; --std=c11 means
>> something very specific (and unchanging)
>
> They do. And that covers what the standard covers. The standard also
> has limits. It includes constructs that are syntactically permitted
> but whose behavior is left undefined, known by the scarred as "UB" for
> "undefined behavior". An example from Clang's discussion is
>
> int i = 10 << 31;
>
> The standard says << is a shift operator. It places no limit on the
> number of bits to be shifted. If that number is so large that the
> product cannot be represented by the assigned variable, that is *not*
> an error. The standard allows the compiler to do anything or nothing
> with it. As you may imagine, the varieties of anything and nothing are
> many.
>
> Compiler writers are well aware that "nothing" is faster done than
> "something". Over time, they have gotten more aggressive in simply
> deleting UB code. As a consequence, programmers who thought they wrote
> standards-conforming code get burned when they upgrade/change
> compilers. Mysterious and sometimes subtle errors are introduced by
> the compiler for the user's benefit.
>
> Your googlefu will turn up lots of discussion. One I liked that wasn't
> on Page 1:
>
>
>
> http://blog.frama-c.com/index.php?post/2013/10/09/Overflow-float-integer
>
> --jkl
> ___
> sqlite-users mailing list
> sqlite-users at mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
___
sqlite-users mailing list
sqlite-users at mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>>>
[sqlite] sqldiff nowadays
On 3/22/16, MM wrote: > Hello, > I can see sqldiff appearing here: > > https://www.sqlite.org/sqldiff.html > > and in the downloads page as part of a linux 32bit binary package. > Alas I don't see any 64bit package. The 32bit binaries will run fine on 64bit machines. > > Given a distro-installed 64bit sqlite binary and libs, which part of the > sources would 1 need to download only sqldiff and build only that, in 64bit > as well. > Download the canonical source code distro and type: ./configure; make sqldiff -- D. Richard Hipp drh at sqlite.org
[sqlite] Article about pointer abuse in SQLite
It is uninitialized. you are setting an initial value within an if
statement. For the compiler, the code has NOT actually executed. so it
does not use the value of the variable arbitrary_true_false. If it was a
#define then it would use the value but still give an error because it
is not a compiler directive #if but a code if.
The logic is that the first instance of assignment is within a
conditional. That is a particularly nasty kind of bug and should be
reported as an error. because if later you decide to change
arbitrary_true_false to false, then s.x would not be initialized before
use. the compiler is correct to issue the warning. Give s.x a value
after/at initialization, but before the if statement to give it a
desired initial value then recompile, that should fix the error.
Compilers only set the code to initialize the variable at declaration,
not actually use the values during compile. If it was declared as a
constant using a compiler directive such as #define, then the compiler
would use the value in the logic and still give an error, but a
different one because the conditional would always evaluate true (or
false depending on what it was set to)
On 03/21/2016 21:31, J Decker wrote:
> On Mon, Mar 21, 2016 at 8:40 PM, Scott Doctor
> wrote:
>> you are missing
>>
>> using System;
> whatever. It still fails because it says the variable is
> uninitilalized. THe only thing that doesn't is actually running it.
>
> That same pattern not matter what the language triggers warning/error checkers
>>
>> Scott Doctor
>> scott at scottdoctor.com
>> --
>>
>>
>> On 3/21/2016 5:21 PM, J Decker wrote:
>>> So far I just see analysis tools fail for the same sorts of valid code...
>>>
>>> this is a bit of C# but the same idea causes the same warnings and
>>> there's nothign tecniclally wrong with this.
>>>
>>>
>>>
>>> class test
>>> {
>>> struct large_struct { public int x; }
>>> bool arbitrary_true_false = true;
>>> void method()
>>> {
>>> bool initialized = false;
>>> large_struct s;
>>> if( arbitrary_true_false )
>>> {
>>>initialized = true;
>>>s.x = 1;
>>> }
>>> if( initialized )
>>> {
>>>Console.WriteLine( "this fails(during compile) as
>>> uninitialized: {0}", s.x );
>>> }
>>> }
>>> }
>>>
>>> On Mon, Mar 21, 2016 at 4:35 PM, James K. Lowden
>>> wrote:
On Mon, 21 Mar 2016 13:48:06 -0700
Scott Perry wrote:
> Compilers allow you to choose your standard; --std=c11 means
> something very specific (and unchanging)
They do. And that covers what the standard covers. The standard also
has limits. It includes constructs that are syntactically permitted
but whose behavior is left undefined, known by the scarred as "UB" for
"undefined behavior". An example from Clang's discussion is
int i = 10 << 31;
The standard says << is a shift operator. It places no limit on the
number of bits to be shifted. If that number is so large that the
product cannot be represented by the assigned variable, that is *not*
an error. The standard allows the compiler to do anything or nothing
with it. As you may imagine, the varieties of anything and nothing are
many.
Compiler writers are well aware that "nothing" is faster done than
"something". Over time, they have gotten more aggressive in simply
deleting UB code. As a consequence, programmers who thought they wrote
standards-conforming code get burned when they upgrade/change
compilers. Mysterious and sometimes subtle errors are introduced by
the compiler for the user's benefit.
Your googlefu will turn up lots of discussion. One I liked that wasn't
on Page 1:
http://blog.frama-c.com/index.php?post/2013/10/09/Overflow-float-integer
--jkl
___
sqlite-users mailing list
sqlite-users at mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>>> ___
>>> sqlite-users mailing list
>>> sqlite-users at mailinglists.sqlite.org
>>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>>>
>>>
>> ___
>> sqlite-users mailing list
>> sqlite-users at mailinglists.sqlite.org
>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
> ___
> sqlite-users mailing list
> sqlite-users at mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
>
--
-
Scott Doctor
scott at scottdoctor.com
[sqlite] big table schema raise memory leak
hi , i m use sqlite 3.8.10.2 on suse 11 with jdk 1.8 jni, when i create much more tables,eg 200k, it can easily found the memory leak when close runed, but when i try linux native c code, it qppears correctly, it really confused me , could anybody tell the diffrence from jni runtime between linux native run time, why the same code run different output? thanks a lot!
