[LLVMdev] DejaGnu test-suite coverage

heisenbug ggreif at gmail.com
Wed May 28 05:16:47 PDT 2008


On May 28, 11:33 am, Duncan Sands <baldr... at free.fr> wrote:
> Hi,
>
> > > I think he means the lines like:
>
> > >     switch (Opcode) {
>
> > > default: assert(0 && "Unknown load!");
>
> > > where the default case is never executed.
>
> > I would personally appreciate expected to fail tests that ensure the
> > assertions actually catch the bad inputs that they were designed to catch,
> > there by executing those lines. I realize that many couldn't be tested in
> > this manner (they assert on malformed data in the middle, which should be
> > caught much earlier). Anyways, I'm gonna go prod the generated files, and
> > see if I can capture at least some of that code.
>
> I don't think assertions should be used to catch malformed input.  Assertions
> should be used to check that impossible things aren't happening, not possible
> things.  The right way to handle malformed input IMHO is to output a message
> and explicitly abort, whether assertions are enabled or not.
>
> In short it should be impossible to get test coverage for assertions because
> by definition they should be impossible to reach.
>
> Ciao,
>
> Duncan.

I completely agree with Duncan. Asserting on false signifies "this
piece of code should not be hit under any circumstances, and if it
happens nevertheless, please ICE out". Asserting in a boolean means "I
expect this invariant to hold, otherwise ICE". Both are not means of
user input validation.

As Chris has correctly deduced, I have meant the former case in my
response. Those "assert(0 && "bla")" lines are unreachable lines by
expectation and should not be counted on the "unexecuted lines" tally.
The cleanest way to count them in the (to be introduced) category
"barrier" and these lines should not end up in the percentage
calculation.

Cheers,

    Gabor

PS: Sorry for breaking the thread, I forgot that I can respond by
groups.ggl.com and have chosen the mailing list web interface
(pipermail?), which sucks :-(

> _______________________________________________
> LLVM Developers mailing list
> LLVM... at cs.uiuc.edu        http://llvm.cs.uiuc.eduhttp://lists.cs.uiuc.edu/mailman/listinfo/llvmdev



More information about the llvm-dev mailing list