[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gpsd-dev] wsg_separation Issue

From: Eric S. Raymond
Subject: Re: [gpsd-dev] wsg_separation Issue
Date: Tue, 8 May 2012 01:02:03 -0400
User-agent: Mutt/1.5.21 (2010-09-15)

Bywater, Rick (SA-1) <address@hidden>:
> Here is a log of a Coverity run on the head as of this morning.  The gpsd.log 
> contains the output from the cov-build while gpsd.log2 contains the 
> cov-analyze output.

Thank you very much.  I would be delighted to help you complete this analysis
by annotating the code in whatever ways might help.

I might be able to help you achieve your objectives better if I understood why
you're being asked to scan GPSD.  Who needs careful verification of this code,
and why?  (Er, if it helps, I already know it's used in military systems.)

> I was going to attach the full c/ directory that Coverity 
> generates so you could see the issues, but the tgz file was over 12 MB and I 
> was afraid that would be rejected by the mailing list.  If you would like 
> that 
> output and the list server is ok with a 12 MB file, let me know and I will 
> post it.  If the list server will reject that size of an upload, let me know 
> where you would like the results posted and I will get them uploaded.

Please mail them to me at address@hidden  I don't think my personal
mailserver will barf.

Hm.  I note a link failure due to clock_gettime() reference.  Do you get this
from a regular build, or is it in the Coverity environment only?  If so, is
there an #ifdef I can use to condition out that call?

This is interesting...

Analysis summary report:
Files analyzed                  : 86
Total LoC input to cov-analyze  : 72824
Functions analyzed              : 585
Classes/structs analyzed        : 128
Paths analyzed                  : 125590
Time taken by Coverity analysis : 00:01:22
Defect occurrences found        : 45 Total
                                   2 BAD_SIZEOF
                                   2 CHECKED_RETURN
                                   4 CONSTANT_EXPRESSION_RESULT
                                   3 DEADCODE
                                  12 FORWARD_NULL
                                   1 INFINITE_LOOP
                                   1 NEGATIVE_RETURNS
                                   1 NULL_RETURNS
                                   1 OVERRUN_DYNAMIC
                                   3 OVERRUN_STATIC
                                   6 RESOURCE_LEAK
                                   1 REVERSE_INULL
                                   7 UNINIT
                                   1 UNREACHABLE

Exceeded path limit of 5000 paths in 1.88% of functions (normally up to 5% of 
functions encounter this limitation)

A gross defect rate of 1 per 1618 lines already makes me pretty happy, and it's
likely from my one previous experience of a full scan that some of those are
false positives. Let's see what we can do to filter out the noise, shall we?
                <a href="";>Eric S. Raymond</a>

reply via email to

[Prev in Thread] Current Thread [Next in Thread]