[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:       Pavel Ivanov <paivanof () gmail ! com>
Date:       2011-09-25 2:05:36
Message-ID: CAG1a4rukJtNQRcnyrkRonT3JSLZOO3bovszyMhzZeUEAxpRfVA () mail ! gmail ! com
[Download RAW message or body]

On Sat, Sep 24, 2011 at 7:35 AM, Sami Liedes <sliedes@cc.hut.fi> 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

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