News for hackers. Stuff that matters.
Re:Stranger Strings: An exploitable flaw in SQLite by taeric on Tuesday October 25, 2022 @04:42PM (#33335878)
I don't think that tracks. Consider:

    if (a) {
       doA();
    }
    if (b) {
       doB();
    }
With (a,b) as (true, false) and (false, true), you satisfy every outcome of each decision test, but you never tested "doA()" and "doB()" at the same time.

I think there is some interpretation of that last bullet, "Each condition in a decision is shown to independently affect the outcome of the decision" that is inline with the idea. But that sounds more like on an statement like:

    if (a && b)
that you test changing the values of a and b independently to show that either one of them can cause the check to pass.
Re:Stranger Strings: An exploitable flaw in SQLite by insanitybit on Tuesday October 25, 2022 @04:45PM (#33335926)
By "this" I meant what I linked, not "what you just said". I realize in retrospect that I was unclear. I'm not sure if their approach would imply satisfying the (true, true)/ (false, false) case given that they are separate branches.
Re:Stranger Strings: An exploitable flaw in SQLite by taeric on Tuesday October 25, 2022 @04:48PM (#33335961)
Right, but I think that is what the original poster meant. There is a "path" through my example that hits both "doA()" and "doB()." And having 100% branch coverage doesn't necessarily get you there. Even under the stricter rule that they are using.
Re:Stranger Strings: An exploitable flaw in SQLite by insanitybit on Tuesday October 25, 2022 @04:49PM (#33335977)
Yep, we're on the same page.
Re:Stranger Strings: An exploitable flaw in SQLite by taeric on Tuesday October 25, 2022 @05:15PM (#33336269)
Coming back to this, I understand your previous post about "this" now. :D Apologies on misunderstanding that the first time around!