Heh,
my ex-boss would die seeing something like this 
Just one comment, does GCOV have a flag for
a third category of lines, like "undesired to execute"?
This would make the summary of
<http://chandlerc.net/llvm-coverage/lib/Target/PowerPC/PPCHazardRecognizers.cpp.gcov.html>
much more favorable.
Nice work!
Cheers,
  Gabor
Heh,
my ex-boss would die seeing something like this
It’s not too hard to produce, let me know if you want details, or ping me on IRC.
Just one comment, does GCOV have a flag for
a third category of lines, like “undesired to execute”?
Nope. I’m a subscriber to the theory that everything should be executed, right down to assertions, and compile assertions. ;] Not always possible, but that is usually my ideal goal in testing. The key is to always check that the result of that execution is correct, so trigger assertions, and catch them, etc.
This would make the summary of
<http://chandlerc.net/llvm-coverage/lib/Target/PowerPC/
PPCHazardRecognizers.cpp.gcov.html>
much more favorable.
I’m not seeing the bad aspect of this particular file? It has pretty good coverage, is code calling into this “bad”? If so, then assertions, or logging or something might be more appropriate. Coverage just says that it got used, not that its use was “correct”. ;]
-Chandler
I think he means the lines like:
switch (Opcode) {
default: assert(0 && "Unknown load!");
where the default case is never executed.
-Chris
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.
-Chandler
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.
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 