3 ms·

> If you’re convinced the code branch can’t ever be taken, you also should be confident that it doesn’t need to be tested. I don't think I would (personally) e

by nimih 1y ago

> If you’re convinced the code branch can’t ever be taken, you also should be confident that it doesn’t need to be tested. I don't think I would (personally) ever be comfortable asserting that a code branch in the machine instructions emitted by a compiler can't ever be taken, no matter what, with 100% confidence, during a large fraction of situations in realistic application or library development, as to do so would require a type system powerful enough to express such an invariant, and in that case, surely the compiler would not emit the branch code in the first place. One exception might be the presence of some external formal verification scheme which certifies that the branch code can't ever be executed, which is presumably what the article authors are gesturing towards in item D on their list of preconditions.

timv 1y ago
The argument here is that they're confident that the bounds check isn't needed, and would prefer the compiler not insert one. The choices therefore are: 1. No bound check 2. Bounds check inserted, but that branch isn't covered by tests 3. Bounds check inserted, and that branch is covered by tests I'm skeptical of the claim that if (3) is infeasible then the next best option is (1) Because if it is indeed an impossible scenario, then the lack of coverage shouldn't matter. If it's not an impossible scenario then you have an untested case with option (1) - you've overrun the bounds of an array, which may not be a branch in the code but is definitely a different behaviour than the one you tested.
- skywhopper 1y ago
  I think you’re misreading their statement. They aren’t saying they don’t want the compiler to insert the additional code. They’re saying they want to test all code the compiler generates.
- nimih 1y ago
  > Because if it is indeed an impossible scenario, then the lack of coverage shouldn't matter. At the point where a load-bearing piece of your quality assurance strategy is 100% branch coverage of the generated machine code, it very much does matter. > I'm skeptical of the claim that if (3) is infeasible then the next best option is (1) In the general case, obviously not. But, in the specific case we’re discussing, which is that (2) has the rider of “the development team will be forced to abandon a heretofore important facet of their testing strategy at the exact moment they are rewriting the entire codebase in a language they are guaranteed to have less expertise in,” I think (1) seems pretty defensible.

by nimih 1y ago

timv 1y ago

The argument here is that they're confident that the bounds check isn't needed, and would prefer the compiler not insert one. The choices therefore are: 1. No bound check 2. Bounds check inserted, but that branch isn't covered by tests 3. Bounds check inserted, and that branch is covered by tests I'm skeptical of the claim that if (3) is infeasible then the next best option is (1) Because if it is indeed an impossible scenario, then the lack of coverage shouldn't matter. If it's not an impossible scenario then you have an untested case with option (1) - you've overrun the bounds of an array, which may not be a branch in the code but is definitely a different behaviour than the one you tested.

skywhopper 1y ago
I think you’re misreading their statement. They aren’t saying they don’t want the compiler to insert the additional code. They’re saying they want to test all code the compiler generates.
nimih 1y ago
> Because if it is indeed an impossible scenario, then the lack of coverage shouldn't matter. At the point where a load-bearing piece of your quality assurance strategy is 100% branch coverage of the generated machine code, it very much does matter. > I'm skeptical of the claim that if (3) is infeasible then the next best option is (1) In the general case, obviously not. But, in the specific case we’re discussing, which is that (2) has the rider of “the development team will be forced to abandon a heretofore important facet of their testing strategy at the exact moment they are rewriting the entire codebase in a language they are guaranteed to have less expertise in,” I think (1) seems pretty defensible.