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