This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Coverity Scan

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 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


Of those you can ignore


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

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.



Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]