[sqlite] Is SQLite supporting x64?
Hello, I download the SQLite source code from the site, I want to compile the source to x64 version using VS2010. I know how to compile application to x64 version with VS2010, but I want to know that is the SQLite code base supporting the x64 platform internally? Because the "Precompiled Binaries For Windows" is provided as win32-x86, so I have such a question. In short, can the SQLite binary file work well also on 64-bit Windows OS? ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] MC/DC coverage explained wrong in the home page?
On Sat, Sep 24, 2011 at 7:35 AM, Sami Liedes wrote: > On Fri, Sep 23, 2011 at 10:26:43PM -0400, Pavel Ivanov wrote: >> > 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 the following: >> >> A; >> // everything inside if >> >> They won't even check the outcome of A and even won't calculate any >> part of A that has no side effects (and it's known at compile time). >> So in an object file A is not a condition and can hardly be called a >> boolean expression. Does (d), (e) and (f) even apply to it? > > That's also entirely beside the point. Using that same argument you > could say you don't need to remove dead code because a clever compiler > does it for you, which is obviously hogwash. Good luck arguing like > that in front of some organization that wants 100% code coverage :) No, that's exactly the point that Richard tries to explain to you and you don't seem to understand. SQLite's testing coverage is a coverage of the resulting object code, not some source code lines. And so it doesn't matter how the code was written, it doesn't matter if it used "if" statement or not. What matters is if resulting assembler has conditional jump instruction or not, if there is branching in the object code or not. And as Richard have shown you there could be pretty legitimate reasons for a "dead code" which is not a bug. And even there could be legitimate reasons for an "if" statement similar to what you've brought up. And if it doesn't result in a branching in the object code then different outcomes of condition A don't matter - they don't change control flow. > Dead code is indicative of a bug. Usually programmers write code only > in the expectation that it be run. The same can be said of conditions > in an if statement, and what the compiler does to it doesn't change > that. Programmers write code expecting it to be executed, right. But also some programs have like 10 or 20 years of history. And all those years were spent not only on writing a new code, but also on doing some changes to the existing one. And sometimes changes in one place can result in a dead code in another. And that doesn't mean that there's a bug. It just means that this code is not needed anymore but nobody deleted it yet. > MC/DC is just a clever way of saying that you must show that each > condition in an if statement really matters. So, your point is if some condition in an if statement doesn't matter developer MUST remove it from if statement before it can claim MC/DC? Well, that's a straight road to a buggy software. Pavel ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Accumulation of windows temp files
On 24 Sep 2011, at 4:31am, Nathan Lawrentschuk wrote: > according to forums I am accumulating sqlite files that are on an hourly > basis accumulating in my windows temp files as "etilqs" files (sqlite > backwards). These are temporary sqlite files being made by a Windows application. Normally the application would delete those files before it exits but either A) there's a bug in the application and it doesn't close the database properly OR B) you are terminating the application before it has a chance to close the database OR C) you have some underlying OS or hardware fault like hard disk corruption. My guess is FireFox or Chrome not being allowed to exit properly. But it might be (C). There is no reason to believe that any virus or other malware is involved. Simon. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] searchable index of previous discussion topics?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/24/2011 09:10 AM, Shorty wrote: > Is there a searchable database of the topics and threads ? Gmane provides an interface and a search function: http://news.gmane.org/gmane.comp.db.sqlite.general > When I run into a snag, I prefer to lookup previous conversations to see how > others have solved the problem. I figure if someone already took the time > to answer that question, I should try to read that first. I'd recommend doing a Google search since it will pick up any relevant conversations be they on the mailing list, Stack Overflow, blogs etc. Roger -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk5+CJ4ACgkQmOOfHg372QQagACgiGzQxwFvITaR6U9a7qNOroIp 6mYAnjIcz4MDEmCr/anc+kwbYDR9eaWC =a6Dt -END PGP SIGNATURE- ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] NUL handling bugs (was Re: c-api document suggestion)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/23/2011 05:51 PM, David Garfield wrote: >> SQLite's API supports both (mostly). Internally, you must use one or >> the other (or hideously duplicate code), Not really. If your own code only uses NUL termination then use that form of APIs. If you use counted strings then use that form. As a developer using SQLite you do not have to use both. And you can mix and match with what is most convenient at each call, although supporting embedded NUL requires the counted form for obvious reasons. >> and SQLite uses the second -- >> except for some functions (which use the hybrid model). That >> exception is the bug. The "bug" is that a performance optimisation is mentioned in the doc. The internal SQL parsing code always stops at a NUL, and requires that a string be NUL terminated. If you do not explicitly provide one then it will copy the string in order to NUL terminate it. Sure this is a little messy and could be explained a little better but it isn't a bug. The internal code could also change in the future to avoid the NUL requirement but I'd expect that to be *really* low in the list of priorities. >> Correction: with the exception of a number of BUILT IN functions. I meant user defined functions in the sense of components of a SQL statement (like verbs, operators and collations are components). Yet another pesky ambiguation introduced by the user word! Note that you can override all built in user defined functions - just register one with the same name. You do however have to ensure that you register variants for the different Unicode encodings. ie you can make your installation of SQLite behave exactly how you want. Should the built in implementations be fixed? IMHO yes, but it isn't a priority. In the 6 years since SQLite 3 has been available you are only the second person to complain. (I was the first :-) >> sqlite3_value_*() and sqlite3_result_*() are fully capable of using >> the counted model, Indeed. It is how I ensure my code is NUL safe/correct. A far bigger bug for those functions is that they use int for the size of data rather than size_t. I did a survey a few years back using google code search and every instance I could find where -1 was not passed in as the length treated them as though they used size_t and would result in (silent) truncation on 64 bit machines. My own code explicitly makes sure the values about to be passed in are less than 2GB. >> Of course, the SQLite shell does it anyway. So "cannot" is not really >> correct. Well you can always spew arbitrary bytes to stdout which generally works for people who only ever use ASCII. But the rule really is that bytes cannot be converted to characters without knowing the encoding. > The SQLite shell isn't particular well structured for easy developer > extension. >> I've seen that... ouch. It is best to think of the shell as a convenience tool for the SQLite developers to throw commands at the library as they add them, not as some formal tool for SQL access. It works reasonably well. >> And your python wrapper is probably implemented using the counted >> string form exclusively. :-) Originally it used whichever forms were most convenient at that place in the code. This is further complicated by Python being compilable with two different forms of Unicode character size and SQLite having UTF8 and UTF16 apis. Then one day I discovered that SQLite allows embedded NUL in string values and made sure my code always works correctly - I'm OCD like that with my wrapper. Roger -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk5+B3cACgkQmOOfHg372QSoPACfRNsbvh4ztr9MtGCQsAtxVMtU 09oAoN+U8AfKsebx+sqoUIKBorNUq6Hz =eFoT -END PGP SIGNATURE- ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] searchable index of previous discussion topics?
On 24-09-2011 18:10, Shorty wrote: I have been to the archive of the message topics: http://sqlite.org:8080/cgi-bin/mailman/private/sqlite-users/ It is difficult to search, it seems like to find information, would need to open each grouping seperately and then manually search through those items. Or I could be missing something and there is an easier way I just don't see right now. Is there a searchable database of the topics and threads ? http://www.mail-archive.com/sqlite-users@sqlite.org/msg64177.html ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] searchable index of previous discussion topics?
I have been to the archive of the message topics: http://sqlite.org:8080/cgi-bin/mailman/private/sqlite-users/ It is difficult to search, it seems like to find information, would need to open each grouping seperately and then manually search through those items. Or I could be missing something and there is an easier way I just don't see right now. Is there a searchable database of the topics and threads ? When I run into a snag, I prefer to lookup previous conversations to see how others have solved the problem. I figure if someone already took the time to answer that question, I should try to read that first. Thanks Shorty ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Accumulation of windows temp files
Nathan, try googling "etilqs" - some interesting (and hopefully helpful) results. As others (including Richard, Sqlite's creator) have said it's absolutely not Sqlite's fault that you are having this problem. Nothing inside Sqlite is causing it, but rather something on your machine that is presumably using Sqlite to temporarily store data, and not cleaning up after itself. Chris > Date: Sat, 24 Sep 2011 13:31:08 +1000 > From: lawrentsc...@gmail.com > To: sqlite-users@sqlite.org > Subject: [sqlite] Accumulation of windows temp files > > Dear SQlite > according to forums I am accumulating sqlite files that are on an hourly > basis accumulating in my windows temp files as "etilqs" files (sqlite > backwards). Quite frankly, this may as well be a virus becuase of the > trouble it is causing and such files are giving your product a bad name in > the webworld. You would be well advised to have a link on your webpage how > to stop this happening (if you are the culprit) as I suspect there are many > angered computer uses out their in cyberspace like myself. Your advice would > be most appreciated. > Regards Nathan > > -- > *A/Prof Nathan Lawrentschuk > *MB BS PhD FRACS (Urology) > *University of Melbourne, Department of Surgery, Austin Hospital > **Urological Surgeon & Urologic Oncologist* > *Suite 5, 210 Burgundy Street* > *Heidelberg Vic 3084* > *AUSTRALIA* > *Tel: +61 3 9387 1000 (call service)* > *+61 3 9455 3269 (rooms)* > *Fax: +61 3 9457 5829* > *Email: lawrentsc...@gmail.com* > ___ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] MC/DC coverage explained wrong in the home page?
On Sat, Sep 24, 2011 at 9:50 AM, Stephan Beal wrote:
> On Sat, Sep 24, 2011 at 3:17 AM, Richard Hipp wrote:
>
> > The object-code branch coverage testing of SQLite clearly fulfills
> > guidelines a, b, c, d, and e. The question at hand is does 100% branch
> > coverage fulfill f in a short-circuit language such as C/C++. Note that
> > the
> > 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.
> >
>
> Maybe this is naive, but what about the definition of constant vs
> non-constant?
They mean compile-time constant. For example, consider the MEMDB symbol in
the pager.c source file of SQLite:
http://www.sqlite.org/src/artifact/8a6ac3e0d969?ln=747-757
If you compile with the SQLITE_OMIT_MEMORYDB option, then this symbol is
fixed a compile-time. That means that decisions such as
http://www.sqlite.org/src/artifact/8a6ac3e0d969?ln=3752
are determined at compile-time (to always be false in this case) and are
therefore not subject to MC/DC coverage analysis. The "true" side of the
"if" statement above is never taken (since MEMDB is always false) but that
does not mean the "true" side is dead code. GCC (and most every other
compiler) is smart enough to know that the "true" side can be completely
omitted from the build. And this is such a trivial optimization that it
happens even at the minimum optimization level, -O0.
> The list describes non-constant bool expressions as having to
> be evaluated with both outcomes.
>
> e.g.
>
> char * x = ...; //user-supplied/non-constant
>
> if( x && *x ) {...)
>
> i would argue (naively, perhaps) that the second expression is const be
> cause once the value of x is set, the value of *x cannot change so long as
> x
> does not change. But that comes down once's definition of const. *x _as an
> expression_ does not exist until it is tried, and it cannot (in
> short-circuit logic) be tried until x evaluates to true (else undefined
> behaviour, as described earlier).
>
> --
> - stephan beal
> http://wanderinghorse.net/home/stephan/
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
--
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Accumulation of windows temp files
On Fri, Sep 23, 2011 at 11:31 PM, Nathan Lawrentschuk < lawrentsc...@gmail.com> wrote: > Dear SQlite > according to forums I am accumulating sqlite files that are on an hourly > basis accumulating in my windows temp files as "etilqs" files (sqlite > backwards). Quite frankly, this may as well be a virus becuase of the > trouble it is causing and such files are giving your product a bad name in > the webworld. You would be well advised to have a link on your webpage how > to stop this happening (if you are the culprit) as I suspect there are many > angered computer uses out their in cyberspace like myself. Your advice > would > be most appreciated. > Regards Nathan > Dear Nathan SQLite is not a computer program or application. It is a library. SQLite is a component piece of many other applications (Firefox, Chrome, iTunes, McAfee, Photoshop, Skype, etc.) But by itself, it is inert. It does nothing on its own. It is not SQLite, then, that is leaving temp files on your machine; it is some other application that is using SQLite as a tool to leave temp files on your machine. By analogy, you can think of SQLite as a car tire. The tires are a very important piece of your car. Without them, you car won't go. But on the other hand, the tires won't go either, unless connected to your car. Now, suppose you woke up one morning and found that a miscreant teenager had used his car to burn donuts on your front lawn. Would you then write a testy missive to Bridgestone or Goodyear complaining that their products were going to get a bad name in the webworld because they had failed to include instructions on their website on how to stop misguided youth from burning donuts with their products? I'm very sorry that your machine is having problems. But on the other hand, the problems are not caused by SQLite. There is nothing we can do to stop it. Nor is nothing we can do to identify the true culprit. > > -- > *A/Prof Nathan Lawrentschuk > *MB BS PhD FRACS (Urology) > *University of Melbourne, Department of Surgery, Austin Hospital > **Urological Surgeon & Urologic Oncologist* > *Suite 5, 210 Burgundy Street* > *Heidelberg Vic 3084* > *AUSTRALIA* > *Tel: +61 3 9387 1000 (call service)* > *+61 3 9455 3269 (rooms)* > *Fax: +61 3 9457 5829* > *Email: lawrentsc...@gmail.com* > ___ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > -- D. Richard Hipp d...@sqlite.org ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] MC/DC coverage explained wrong in the home page?
On Sat, Sep 24, 2011 at 3:17 AM, Richard Hipp wrote:
> The object-code branch coverage testing of SQLite clearly fulfills
> guidelines a, b, c, d, and e. The question at hand is does 100% branch
> coverage fulfill f in a short-circuit language such as C/C++. Note that
> the
> 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.
>
Maybe this is naive, but what about the definition of constant vs
non-constant? The list describes non-constant bool expressions as having to
be evaluated with both outcomes.
e.g.
char * x = ...; //user-supplied/non-constant
if( x && *x ) {...)
i would argue (naively, perhaps) that the second expression is const be
cause once the value of x is set, the value of *x cannot change so long as x
does not change. But that comes down once's definition of const. *x _as an
expression_ does not exist until it is tried, and it cannot (in
short-circuit logic) be tried until x evaluates to true (else undefined
behaviour, as described earlier).
--
- stephan beal
http://wanderinghorse.net/home/stephan/
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] EXT : Accumulation of windows temp files
Google Chrome creates those on my system (Win XP64) in "Documents and Setting\username\Local Settings\Temp Are you using Chrome? A polite shutdown of Chrome deletes it's current file. A rude shutdown will leave it there. It's not an sqlite bug or virusit's an application doing it. Might also be a FireFox thing. Where are your files located? Michael D. Black Senior Scientist NG Information Systems Advanced Analytics Directorate From: sqlite-users-boun...@sqlite.org [sqlite-users-boun...@sqlite.org] on behalf of Nathan Lawrentschuk [lawrentsc...@gmail.com] Sent: Friday, September 23, 2011 10:31 PM To: sqlite-users@sqlite.org Subject: EXT :[sqlite] Accumulation of windows temp files Dear SQlite according to forums I am accumulating sqlite files that are on an hourly basis accumulating in my windows temp files as "etilqs" files (sqlite backwards). Quite frankly, this may as well be a virus becuase of the trouble it is causing and such files are giving your product a bad name in the webworld. You would be well advised to have a link on your webpage how to stop this happening (if you are the culprit) as I suspect there are many angered computer uses out their in cyberspace like myself. Your advice would be most appreciated. Regards Nathan -- *A/Prof Nathan Lawrentschuk *MB BS PhD FRACS (Urology) *University of Melbourne, Department of Surgery, Austin Hospital **Urological Surgeon & Urologic Oncologist* *Suite 5, 210 Burgundy Street* *Heidelberg Vic 3084* *AUSTRALIA* *Tel: +61 3 9387 1000 (call service)* *+61 3 9455 3269 (rooms)* *Fax: +61 3 9457 5829* *Email: lawrentsc...@gmail.com* ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Do I still need an index if I have a composite Primary Key(or UNIQUE)
Florian Kusche wrote: > in my application, an Icon is made up of one or more layers of images: > > CREATE TABLE IconLayer > ( > IconID INTEGER NOT NULL, > Order INTEGER NOT NULL, > ImageID INTEGER NOT NULL REFERENCES Image( _id ), > > PRIMARY KEY ( IconID, Order ) > ); > > During runtime, I want to get the layers of my Icons: > > SELECT ImageID FROM IconLayer WHERE IconID=xyz ORDER BY Order > > Do I still need an index on the column IconID, or is the primary key > sufficient, because it already contains the IconID? Primary key is sufficient. For the future, run your query with the words "EXPLAIN QUERY PLAN" prepended in front - this will tell you exactly which indexes are used for which tables when executing the query. > Is this dependant on the order of the columns in the primary key? Yes. The order you have them in is will suited for this query. > i.e.: if no additional index is needed, would it still work, if > the primary key was "PRIMARY KEY ( Order, IconID )" ? This index could still be used, but only to satisfy ORDER BY clause. A condition on IconID would have required a full table scan. -- Igor Tandetnik ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] Do I still need an index if I have a composite Primary Key (or UNIQUE)
Hi, in my application, an Icon is made up of one or more layers of images: CREATE TABLE IconLayer ( IconID INTEGER NOT NULL, Order INTEGER NOT NULL, ImageID INTEGER NOT NULL REFERENCES Image( _id ), PRIMARY KEY ( IconID, Order ) ); During runtime, I want to get the layers of my Icons: SELECT ImageID FROM IconLayer WHERE IconID=xyz ORDER BY Order Do I still need an index on the column IconID, or is the primary key sufficient, because it already contains the IconID? Is this dependant on the order of the columns in the primary key? i.e.: if no additional index is needed, would it still work, if the primary key was "PRIMARY KEY ( Order, IconID )" ? Thanks for your help! Florian ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] Accumulation of windows temp files
Dear SQlite according to forums I am accumulating sqlite files that are on an hourly basis accumulating in my windows temp files as "etilqs" files (sqlite backwards). Quite frankly, this may as well be a virus becuase of the trouble it is causing and such files are giving your product a bad name in the webworld. You would be well advised to have a link on your webpage how to stop this happening (if you are the culprit) as I suspect there are many angered computer uses out their in cyberspace like myself. Your advice would be most appreciated. Regards Nathan -- *A/Prof Nathan Lawrentschuk *MB BS PhD FRACS (Urology) *University of Melbourne, Department of Surgery, Austin Hospital **Urological Surgeon & Urologic Oncologist* *Suite 5, 210 Burgundy Street* *Heidelberg Vic 3084* *AUSTRALIA* *Tel: +61 3 9387 1000 (call service)* *+61 3 9455 3269 (rooms)* *Fax: +61 3 9457 5829* *Email: lawrentsc...@gmail.com* ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] MC/DC coverage explained wrong in the home page?
On Sat, Sep 24, 2011 at 7:49 AM, Sami Liedes wrote: > > The example is a four-input AND gate with short-circuit logic (_ = > don't care/not evaluated). This would be a sufficient set of tests: > > expression = (A && B && C && D) > > #A B C D Result > 11 1 1 1 1 > 20 _ _ _ 0 > 31 0 _ _ 0 > 41 1 0 _ 0 > 51 1 1 0 0 > The SQLite test suite does this full set of tests. > > Am I correct that your approach would consider these two test cases > sufficient? > > #A B C D Result > 11 1 1 1 1 > 20 0 0 0 0 > > Right? > No. Your second example does not provide 100% branch coverage. The compiler will code the decision something like this: if( !A ) goto false; if( !B ) goto false; if( !C ) goto false; if( !D ) goto false; expression = 1; goto end; false: expression = 0; end: We verify in SQLite that each of the 4 branch operations in the pseudocode above is evaluated at least once in each direction. That means we need 5 test cases: (0,x,x,x), (1,0,x,x), (1,1,0,x), (1,1,1,0), and (1,1,1,1). > > But with these test cases, assuming short-circuit, only condition A > has been shown to "independently affect the expression's outcome". The > NASA document correctly points out that even with short-circuit you > need to show that each of the conditions really matters in some case > if you want MC/DC coverage. > I have not read the NASA document yet (I just pulled it up and I've not run across it before) but it looks like they are arguing my point. I'll read it today and let you know. > >Sami > > ___ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > -- D. Richard Hipp d...@sqlite.org ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] MC/DC coverage explained wrong in the home page?
On Sat, Sep 24, 2011 at 04:58:35AM +0300, Sami Liedes wrote: > 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 control statement (i.e., branchpoint) in the program has taken > > all possible outcomes (i.e., branches) at least once; > > d) Every non-constant Boolean expression in the program has evaluated to > > both a True and a False result; > > e) Every non-constant condition in a Boolean expression in the program has > > evaluated to both a True and a False result; > > f) Every non-constant condition in a Boolean expression in the program has > > been shown to independently affect that expression's outcome. > > 2. Based upon these definitions: > > • Statement Coverage requires (a) only > > • DC requires (b, c, d) > > • MC/DC requires (b, c, d, e, f) > > -- Very well. NASA has an example with short-circuit where they treat unevaluated conditions as "don't cares". It's clear from the example that (e) still does not suffice -- it does *not* imply (f). NASA's A Practical Tutorial on Modified Condition/ Decision Coverage: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.6.1317&rep=rep1&type=pdf The example is a four-input AND gate with short-circuit logic (_ = don't care/not evaluated). This would be a sufficient set of tests: expression = (A && B && C && D) #A B C D Result 11 1 1 1 1 20 _ _ _ 0 31 0 _ _ 0 41 1 0 _ 0 51 1 1 0 0 Am I correct that your approach would consider these two test cases sufficient? #A B C D Result 11 1 1 1 1 20 0 0 0 0 Right? But with these test cases, assuming short-circuit, only condition A has been shown to "independently affect the expression's outcome". The NASA document correctly points out that even with short-circuit you need to show that each of the conditions really matters in some case if you want MC/DC coverage. Sami ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] MC/DC coverage explained wrong in the home page?
On Fri, Sep 23, 2011 at 10:26:43PM -0400, Pavel Ivanov wrote: > > 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 the following: > > A; > // everything inside if > > They won't even check the outcome of A and even won't calculate any > part of A that has no side effects (and it's known at compile time). > So in an object file A is not a condition and can hardly be called a > boolean expression. Does (d), (e) and (f) even apply to it? That's also entirely beside the point. Using that same argument you could say you don't need to remove dead code because a clever compiler does it for you, which is obviously hogwash. Good luck arguing like that in front of some organization that wants 100% code coverage :) Dead code is indicative of a bug. Usually programmers write code only in the expectation that it be run. The same can be said of conditions in an if statement, and what the compiler does to it doesn't change that. MC/DC is just a clever way of saying that you must show that each condition in an if statement really matters. Sami ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
