| Subject: | gcov2perl suspectible to different usage of same C/C++ include file (esp. templates) |
After applying the patches of my reports 44864 and 45028 I noticed a
third problem where gcov2perl in combination with cover leads to
incorrect results. The problem again occurs for the instances of
include files. gcov is called with option -l (--long-file-names) in
order to get coverage data for all statements inside of include files
(e.g. inline methods/functions).
The coverage database is build on the assumption that each gcov run for
identical (include) files marks the same lines as executable code lines.
Unfortunately this assumption is not always true. Especially sensitive
are C++ templates. Consider the following example, a default
constructor for a C++ template:
template<size_t LENGTH> inline
TFixString<LENGTH>::TFixString()
{
TFixStringBase::copystring(m_Str, LENGTH, "", 0);
}
Depending on whether the default constructor is actually used in a C++
source (.cc or .cpp) it will be instantiated (created) or not. So the
possible corresponding gcov results can be like the following:
1. (constructor is used):
-: 66:TFixString<LENGTH>::TFixString()
216: 67:{
216: 68: TFixStringBase::copystring(m_Str, LENGTH, "", 0);
-: 69:}
2. (constructor can be used, but isn't):
-: 66:TFixString<LENGTH>::TFixString()
#####: 67:{
#####: 68: TFixStringBase::copystring(m_Str, LENGTH, "", 0);
-: 69:}
3. (constructor can not be used):
-: 66:TFixString<LENGTH>::TFixString()
-: 67:{
-: 68: TFixStringBase::copystring(m_Str, LENGTH, "", 0);
-: 69:}
Coverage data for includes where case 3 and at least one of the other
two cases occur will be counted incorrect as gcov2perl doesn't match
coverage count with line numbers directly. The cover.12 file contains a
simple list of coverage counts for each line of a source that has been
considered executable (not matching '^ *-:') in that instance while the
list of the actual line numbers are stored in one file per source (==
only once and not for each incarnation) in the structure directory.
While this is good as it possible saves a lot of disk space this results
in bad data for something like above example.
I guess fixing this would be a major effort as it needs redesigning the
database of Devel::Cover but please keep this problem in mind whenever
you are going to change that DB design anyway.