Excluding specific branches from coverage results

[Mortron144]

I have a case in which inline functions result in more branches on a line than are easily visible from the code:

deque.empty() is inlined to deque.m_head == deque.m_tail and that, in turn, expands with:

    friend bool operator==(DequeIter const& lhs, DequeIter const& rhs) noexcept
    {
        return (lhs.m_elems == rhs.m_elems) && 
               (lhs.m_norm == rhs.m_norm) &&
               (lhs.m_pos == rhs.m_pos);
    }

I really don't need to test (nor am I sure I COULD test) the m_norm not equal branch in places where I use .empty(), but if I use LCOV_EXCL_BR_LINE I will lose ALL of the branch coverage for .empty().

Has anyone suggested or tried to implement something like LCOV_EXCL_BR[x] to exclude a specific branch from counting against the coverage, where x is an index into the branches present on the line?

[henry2cox]

Has anyone suggested or tried to implement something like LCOV_EXCL_BR[x] to exclude a specific branch from counting against the coverage, where x is an index into the branches present on the line?

For Verilog code: yes. For C/C++: no (at least to my knowledge).
Not hugely hard to implement - though if we take a cue from the verilog feature, the specification of don't cares can get a bit complex.

[henry2cox]

Another observation: if you are using a differential coverage methodology, then branches that you investigated and signed off will appear in a different category than new/changed code in your next build. You won't need to check then again unless/until your code changes, and they change category to one you know you need to look at.
This may go partway to achieving your goal, without the actual exclusion feature.

[Mortron144]

Good point, but we're not using differential.

[henry2cox]

At the risk of going philosophical:
Exclusions are good when your goal is 100% coverage and the cover points in question are unreachable.
The issue is that a 100% target is not always practical or economically viable, especially given the presence of legacy and 3rd party code. It may not be clear whether a particular state is reachable or not, you might not have the resources to go after a particularly deep state - and so on.
That makes "not reached but not changed since you signed off" a useful concept - especially since it provides the opportunity to realize windfall gains in future (say, from constrained random, fuzzing, or some other technique), as well as "covered previously but lost now" issues that are sometimes caused by otherwise undetected bugs. <Probably unwise to relate war story here.>.

It isn't accidental that quite complex exclusion models are implemented for hardware languages: cost of escapes is much, much higher, and 100% of reachable coverpoints is the target. (Yeah: plus a lot of other targets as well.)

None of this means that more precise exclusion mechanisms for software/firmware would not be useful - just explains why we don't seem to have them yet.

Henry

[Mortron144]

Agreed on all counts. I'm working on 100% new, safety critical, embedded code though, so 100% is the name of the game. :) I'm hoping that might be reason enough for me to finally get involved in some OSS dev for the first time. We'll see. ;)