Re: [sqlite] MC/DC coverage explained wrong in the home page?

On Sep 23, 2011, at 9:17 PM, Richard Hipp wrote: > paper above completely ignores this issue. It is as if the authors had > never heard of short-circuit evaluation. Or, perhaps they are familiar with > the problem but could not reach agreement on its solution so simply didn't > bring it up.

Re: [sqlite] MC/DC coverage explained wrong in the home page?

>   if (A || 1) ... > > You can get (e) by giving test cases for A and !A, but most certainly > flipping A does not "independently affect the outcome" as required by > the plain reading of (f). I'm pretty sure that the latest versions of modern compilers will optimize the above if statement to

Re: [sqlite] MC/DC coverage explained wrong in the home page?

On Fri, Sep 23, 2011 at 09:17:43PM -0400, Richard Hipp wrote: > -- > 1. Structural coverage guidelines are: > a) Every statement in the program has been invoked at least once; > b) Every point of entry and exit in the program has been invoked at least > once; > c) Every

Re: [sqlite] MC/DC coverage explained wrong in the home page?

On Fri, Sep 23, 2011 at 5:57 PM, Sami Liedes wrote: > [Note: In case my explanations are not clear enough, there's a fairly > formal position paper by Certification Authorities Software Team > (CAST-10) clarifying MC/DC here: > > >

Re: [sqlite] NUL handling bugs (was Re: c-api document suggestion)

Roger Binns writes: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 09/23/2011 08:47 AM, David Garfield wrote: > > But that is the point. Strings are generally defined in two ways. > > Either: > > > > 1) a pointer, and count every byte up to but not including a NUL. > > > > 2) a

Re: [sqlite] MC/DC coverage explained wrong in the home page?

On 23 Sep 2011, at 11:30pm, Darren Duncan wrote: > This is why I think it is valuable for a programming language to provide > multiple versions of some operations such as boolean "and","or" where one > variant doesn't short-circuit and the other does. > > The primary purpose, then, of

Re: [sqlite] NUL handling bugs (was Re: c-api document suggestion)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/23/2011 08:47 AM, David Garfield wrote: > But that is the point. Strings are generally defined in two ways. > Either: > > 1) a pointer, and count every byte up to but not including a NUL. > > 2) a pointer and a length, and count every byte in

Re: [sqlite] MC/DC coverage explained wrong in the home page?

Richard Hipp wrote: Opinions vary on the exact meaning of MC/DC for a language (such as C) that has short-circuit boolean operators. There are problems with this view, though. In many instances, B is undefined when A is false. In other words, if A is false, any attempt to calculate B will

Re: [sqlite] MC/DC coverage explained wrong in the home page?

[Note: In case my explanations are not clear enough, there's a fairly formal position paper by Certification Authorities Software Team (CAST-10) clarifying MC/DC here: http://www.faa.gov/aircraft/air_cert/design_approvals/air_software/cast/cast_papers/media/cast-10.pdf ] On Fri, Sep 23,

Re: [sqlite] MC/DC coverage explained wrong in the home page?

On Fri, Sep 23, 2011 at 1:51 PM, Sami Liedes wrote: > > > For a decision of the form: > > > > if( A && B )... > > > > The test suite for SQLite tries at least three cases: > > > >(1) A false > >(2) A true and B false > >(3) A true and B true > > > > You

Re: [sqlite] MC/DC coverage explained wrong in the home page?

On Fri, Sep 23, 2011 at 11:16:37AM -0400, Richard Hipp wrote: > Opinions vary on the exact meaning of MC/DC for a language (such as C) that > has short-circuit boolean operators. You are advocating a more rigorous > view of MC/DC that what I have heard before. This is not to say it is > wrong,

Re: [sqlite] NUL handling bugs (was Re: c-api document suggestion)

But that is the point. Strings are generally defined in two ways. Either: 1) a pointer, and count every byte up to but not including a NUL. 2) a pointer and a length, and count every byte in the specified length. If you have a specified length, the length matters, and NULs do not. NUL is a

Re: [sqlite] MC/DC coverage explained wrong in the home page?

Opinions vary on the exact meaning of MC/DC for a language (such as C) that has short-circuit boolean operators. You are advocating a more rigorous view of MC/DC that what I have heard before. This is not to say it is wrong, only different. For a decision of the form: if( A && B )... The

Re: [sqlite] select where date < 30 days ago

Miklos, have you tried something like SELECT * FROM ticket WHERE time BETWEEN '2011-08-01' AND '2011-09-01'; ? I have my "time" as current_timestamp and gives me data like "2011-09-23 17:44:48", so using the above method works just fine with me. > >From:

Re: [sqlite] DISTINCT on a JOIN

> course1 number-of-people-involved-in-course1 number-of-tasks-involved-in-course1 > course2 number-of-people-involved-in-course2 number-of-tasks-involved-in-course2 > course3 number-of-people-involved-in-course3 number-of-tasks-involved-in-course3 > course4

Re: [sqlite] c-api document suggestion

On 23 Sep 2011 at 11:18, Mirek Suk wrote: > Dne 23.9.2011 4:41, Igor Tandetnik napsal(a): >> Note that I didn't say it was wise to store NUL characters as part of the >> string - I only said that you could do it if you wanted to. sqlite3_bind_text >> takes the length

Re: [sqlite] DISTINCT on a JOIN

On 23 Sep 2011, at 12:57pm, Igor Tandetnik wrote: > select name, >(select count(*) from people where course=courses.id), >(select count(*) from tasks where course=courses.id) > from courses; Thank you thank you thank you Igor. I must learn how to use sub-selects properly. Simon.

Re: [sqlite] c-api document suggestion

Mirek Suk wrote: > I just find entire nul handling in SQLite strange. it's C API why not > expect C (that is nul terminated) strings. Because some people do want to store strings with embedded NULs, for various reasons. If you don't, just pass -1 for length and be done with

Re: [sqlite] Assertion in Sqlite 3.7.x on Cygwin using WAL

I'll get to my Windows PC at Sunday and I'll do it Thanks   Artyom Beilis -- CppCMS - C++ Web Framework: http://cppcms.sf.net/ CppDB - C++ SQL Connectivity: http://cppcms.sf.net/sql/cppdb/ > >From: Richard Hipp >To: Artyom

Re: [sqlite] DISTINCT on a JOIN

Simon Slavin wrote: > I have a setup which I will simplify as follows: > > There is a table of courses. > Every course can have any number of people working on it. > Every course involves any number of tasks. > > I want to make a SELECT which will return a table as

[sqlite] DISTINCT on a JOIN

I have a setup which I will simplify as follows: There is a table of courses. Every course can have any number of people working on it. Every course involves any number of tasks. I want to make a SELECT which will return a table as follows: course1 number-of-people-involved-in-course1

[sqlite] undefined symbol: sqlite3_version.

I have copied the C programe in http://sqlite.org/quickstart.html and try to compile it. With BorlandC and TCC I obtain the unique same error: "undefined symbol: sqlite3_version". SQLITE_API const char sqlite3_version[] = SQLITE_VERSION; is in line 693 and 110173 (ifndef SQLITE_AMALGAMATION

Re: [sqlite] NUL handling bugs (was Re: c-api document suggestion)

On Thu, Sep 22, 2011 at 7:53 PM, David Garfield < garfi...@irving.iisd.sra.com> wrote: > As far as I am concerned, this is a SERIOUS bug in sqlite. SQLite does whatever you ask it to do. It makes no attempt to enforce good string hygiene. If you hand it well-formed strings, it gives the

Re: [sqlite] c-api document suggestion

On 23 Sep 2011, at 11:18am, Mirek Suk wrote: > I just find entire nul handling in SQLite strange. it's C API why not expect > C (that is nul terminated) strings. That's more or less the problem: C expects 0x00 termination. But SQLite3 is written to support UTF-8 and UTF-16 strings of

Re: [sqlite] c-api document suggestion

Dne 23.9.2011 4:41, Igor Tandetnik napsal(a): Mira Suk wrote: On 9/21/2011 21:22 Igor Tandetnik wrote: You can include the NUL terminator, if you want it to actually be stored in the database. Actually you can't - if you do all SQL string functions will not work. to be

Re: [sqlite] Newbie starting off question

On Fri, Sep 23, 2011 at 12:02 PM, Simon Slavin wrote: > Not a problem. If your platform allows it, and your compiler can make it > happen, do it. Problems related to that stuff come down to multi-process > and multi-thread oversights, not using the same library from many

Re: [sqlite] Newbie starting off question

On 23 Sep 2011, at 10:17am, david wrote: > It is an embedded system so I have full control of everything. Due to memory > size constraints the ideal thing for me would be to use a shared library. > According to the first post, sharing a library between cgi modules and an > application should

[sqlite] Newbie starting off question

Thanks guys It is an embedded system so I have full control of everything. Due to memory size constraints the ideal thing for me would be to use a shared library. According to the first post, sharing a library between cgi modules and an application should not be a problem? David

Re: [sqlite] LEFT JOIN optimization

On 09/23/2011 04:01 AM, Mira Suk wrote: EXPLAIN QUERY PLAN SELECT DISTINCT ItemsME.Points FROM (ItemsME_Properties LEFT JOIN ItemsME ON ItemsME_Properties.IDR = ItemsME.IDR) WHERE ItemsME.IDR IN (SELECT IDR FROM cProds WHERE Prod = 106) selectidorderfromdetail 000SCAN

[sqlite] System.Data.SQlite Version 1.0.65 (3.7.7.1) much slower than 1.0.74 (3.6.16) !??

Hello I have been using System.Data.SQlite for over a year. Recently I downloaded the latest version, hoping to obtain better performance. Instead I was astonished to find that processing with the new version takes about TWICE THE TIME as with the old version. This is what my