This info can be useful in some cases.
This list is followed by two lines containing the number of functions
found and hit:
FNF:<number of functions found>
FNH:<number of function hit>
Branch coverage summaries are stored in two lines:
BRF:<number of branches found>
BRH:<number of branches hit>
At the end of a section, there is a summary about how many lines were
found and how many were actually instrumented:
LH:<number of lines with a non-zero execution count>
LF:<number of instrumented lines>
Available in v0.1.24 - please let me know if things don't look ok. Thanks for reporting the issue!
Things might not be looking okay. See davglass/lcov-parse#3.
I'm working on posting Istanbul output to Coveralls, so the lcov report is being parsed by this lcov-parse library. Which utilities have you used the Istanbul lcov output with?
I have a patch that checks to see if there are any branches before printing branch summaries, same for functions. If you do decide that this is the correct behavior, please do me the honor of allowing me to submit a pull request.
Sure, go ahead. The problem I have always had with lcov is that I don't see a documented spec for that format.
So, it's always difficult for me to tell whether what I'm doing follows the spec or not. If you have a link to some form of a spec, please do update this issue with that link.
Also, you should feel free to submit a pull request without have to ask about it. I will let you know if I want to merge it in or not (with good reasons either way)
One more thing. Can you install the lcov tool and use the genhtml command to produce the HTML report on the istanbul-generated lcov.info file? I would like to see how it behaves. If it behaves nicely it would imply that the format follows the implicit spec and @davglass needs to change lcov-parse to handle this case.
The genhtml tool works with the zero BRF and BRH, so I imagine that lcov-parse should also handle this case. I've already worked up a patch for lcov-parse, so I'll submit that for now.