Strategies for using adjustments

The PureCoverage adjustment feature requires you to adopt an appropriate strategy for adapting it to your own situation. This topic raises considerations that can influence your use of the feature, and suggests two possible usage models.

Adjustment usage considerations

To use the PureCoverage adjustments feature in the most efficient and productive way, keep the following considerations in mind as you develop your strategy.

Can you use adjusted coverage?

Does your development and testing methodology permit the use of adjusted coverage?

If not, there is no requirement to use the adjustment feature. PureCoverage still provides you with the actual coverage data.

The ADJUSTED LINES column header appears in the Viewer by default, even if you do not use the adjustment feature. To change the header, select View > Select columns . . . in the PureCoverage Viewer. Then select columns from the Actual Line Coverage category instead of the Adjusted Line Coverage category. Also, use Select sorting order in the View menu to reflect actual coverage. to turn the column off, set the appropriate Xresources by swapping the values of the showAdjustedLinesXxxxx and showLinesXxxxx resources in ~/.purecov.Xdefaults. Also, set the default sort to reflect actual coverage.

Who can make adjustments?

Who is permitted to insert adjustments into the code? What rules must they follow?

Many answers are possible. Here is one:

Allow any developer to insert any type of adjustment into the code. For tested and deadcode adjustments, the developer must also add a comment nearby, indicating who made the adjustment, when the adjustment was applied, and why the code is dead or how it was tested. The exact placement of the comments depends on your compiler. For example:

void ErrExit(char * message)
{
    fflush(stdout);
    fprintf(stderr, "\nError: %s\n", message);
    fflush(stderr);
    exit(1);    /* pat 12/11/98: exit is a non-returning */
                /* function, so this 'return' line is */
}               /* unreachable. purecov: deadcode */

void *SafeMalloc(int num_bytes)
{
    int real_num_bytes = num_bytes < 1? 1 : num_bytes;
    char *ptr         = (char *)malloc(real_num_bytes);
    if (ptr == NULL) {              /* pat 12/11/98: I used */
                                    /* dbx to force ptr */
                                    /* null; this worked. */
        ErrExit("out of memory");   /* purecov: tested */
    } else {
        memset(ptr, 0, real_num_bytes);
    }
    return(ptr);

}

Inspected adjustments also require a comment nearby including the developer's name, the date, and the name of another person who has also examined the code and agrees with the placement of the inspected adjustment.

However, many groups that follow informal development methodologies find this approach too strict. The main point is that everyone in the group must mean the same thing when they mark a line of code with an adjustment.

When are adjustments applied?

When are adjustments applied to the data, and how is the database of adjustments maintained?

This question has many practical day-to-day implications. Its answer depends on the model your development group follows, as discussed in the next section.

Models for using PureCoverage adjustments

This section describes two models for using the PureCoverage adjustments feature.

Full-usage model

The model that makes the most thorough utilization of the adjustment features is one in which adjustments are always applied by all the developers. This implies complete integration of adjustments into the daily build system.

Under this model, you can modify the cc rule in your makefiles for compiling source files to .o files. For example, instead of:

.c.o:
    $(COMPILE.c) -o $% $<


you can use:

.c.o:
    $(COMPILE.c) -o $% $<
    purecov -extract $<

The additional step says that whenever a C file has been changed, not only must the file be recompiled, but the updated coverage adjustments must also be extracted from it.

Any time the PureCoverage Viewer is started, it loads the adjustments from ~/.purecov.adjust, so coverage for the program is always adjusted.

The advantages of this method are that adjustments are always up-to-date, and that no effort other than the initial makefile setup is required.

The disadvantages are that the makefiles must be modified globally. Everyone has to agree to use this approach, which is not possible if some groups are not using PureCoverage, or if some developers do not have a license. It also requires a small amount of extra time for extracting adjustments during every compilation.

Single-user model

This is a good way to operate if an individual uses PureCoverage with adjustments in a group that, for any reason, does not want to include PureCoverage in its makefiles.

Under this model, when you are examining coverage data in the PureCoverage Viewer, select Extract adjustments from all source files from the Adjustments menu. This applies all current adjustments to the display.

You can then add appropriate adjustments to the source files interactively as your analysis proceeds. You can save the adjusted source file and the ~/.purecov.adjust file by selecting Save from the File menu in the Annotated Source window.

The main difference between this model and the full-usage model is that the user has to maintain the adjustments manually, since the makefiles do not take care of it automatically.

If you use scripts instead of the Viewer to analyze coverage data, you can use the command:

purecov -extract *.c

to extract the adjustments from your source files.