Re: Coverity Scan

[David Stacey <drstacey@tiscali.co.uk>]

On 17/05/14 11:12, Corinna Vinschen wrote:
> On May 16 21:00, David Stacey wrote:
>> OK - we're in! You can find our project page at 
>> https://scan.coverity.com/projects/2250. Off the list, I've sent 
>> e-mails to Corinna and CGF inviting them to join the project ;-) 
> I got no such mail.  You didn't try the account I'm using for the
> mailing list, I hope?  Please use my company address vinschen AT
> redhat DOT com.

Apologies - another invitation sent to the correct e-mail address. 
Further apologies if I should have known your correct e-mail address 
already!

> I have no idea how this works. I had hoped I'd just get emails with 
> the scan results, the less fancy the solution, the better. We can set 
> this up using gpg encrypted mails, that would be the most elegant 
> solution, IMHO. 

I could probably get Coverity Scan to ping you an e-mail if a new defect 
is introduced. It's probably best if you look at the web page above. 
Once you accept the invitation and log in, you'll see a button to view 
the defects. For each defect, you'll see the defect itself, along with 
the path that the analysis engine took to get there.

For example, consider the case of reading an uninitialised variable. The 
trace would start at the point the variable is declared. You would see 
the path taken through the code (e.g. taking the 'true' path of an 'if' 
statement, or not executing a 'while' loop because the condition was 
never satisfied) until you arrive at a line where the variable is read 
without ever having been initialised. This is more useful than simply 
complaining about reading an uninitialised variable: often these can be 
logic errors, i.e. the coder didn't consider a certain scenario, or 
thought that all paths through the code would initialise the variable at 
some point. As Coverity shows you the path through the code (even 
between functions), you see the hole in the logic.

>> There is still a little work to do in setting up the Coverity scan. The next
>> step is to group the code into logical clusters, which Coverity calls
>> Components. Typically, this is done on directories or other file groupings,
>> and the tool allows you to concentrate on just one of these components at
>> once. If you let me know what components you'd like, I'll set them up.
> Well, the problem is that we're going to switch to git pretty soon, and
> that will slightly change the directory layout.  But basically, in the
> winsup dir, you see the subdirs
>
>    cygserver
>    cygwin
>    doc
>    lsaauth
>    testsuite
>    utils
>
> Of those you can ignore
>
>    doc
>    testsuite
>
> The other four would be natural groups, I think.  The toplevel and
> winsup dirs don't need to be scanned either.

I've set up components for cygserver, cygwin, utils and newlib. There 
were no defects found in 'lsaauth' (which needs investigation in itself 
- I'll look at this). If our directory structure is going to change when 
we move to git then that is OK - I'll remap the components at the point 
we move. However, be aware that reorganising things can confuse Coverity 
- if you sign off any warnings as 'won't fix' then they may reappear if 
the offending code is moved into a different class or file.

> You are aware that we need a copyright assignment from you if you'd 
> like to provide patches, right? Please have a look at the "Before you 
> get started" section of http://cygwin.com/contrib.html

I'll limit my patches to the trivial kind that are ten lines or less. My 
present employer is amazingly supportive of the open source work that I 
do in my own time, and that boat doesn't need rocking.

> In theory, at the time of writing this, I'd suggest to include only cgf,
> yaakov, and me.

I've sent an invitation to Yaakov also.

Cheers,

Dave.


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple