[prev in list] [next in list] [prev in thread] [next in thread] 

List:       sqlite-users
Subject:    Re: [sqlite] MC/DC coverage explained wrong in the home page?
From:       Richard Hipp <drh () sqlite ! org>
Date:       2011-09-24 14:22:38
Message-ID: CALwJ=Mza8=3XDOFzKoKNmxrS3paNkxm60DDV7GoWX57Zr9qO0w () mail ! gmail ! com
[Download RAW message or body]

On Sat, Sep 24, 2011 at 9:50 AM, Stephan Beal <sgbeal@googlemail.com> wrote:

> On Sat, Sep 24, 2011 at 3:17 AM, Richard Hipp <drh@sqlite.org> 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
drh@sqlite.org
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[prev in list] [next in list] [prev in thread] [next in thread]