[haiku-development] Re: New Coverity scan results online: r39894 nightly-raw gcc4 build
- From: Urias McCullough <umccullough@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Wed, 22 Dec 2010 16:37:36 -0800
On Wed, Dec 22, 2010 at 4:07 PM, John Scipione <jscipione@xxxxxxxxx> wrote:
>> I suppose one could perhaps transcribe them all to a public location -
>
> I suppose that their isn't an export option. :(
Nope. Not that I have seen.
I just verified in their license agreement - transcribing the data to
a public location automated or manual is also a violation: "You also
agree that you will not use any robot, spider, other automated device,
or manual process to monitor or copy any content from the Service
without prior approval from Coverity."
See here: http://scan.coverity.com/policy.html
> I want a place that lists each CID number with a short description. If you
> would be willing to make these CID's available to the public I'd be willing
> to transcribe them.
I'm not sure how reasonable they can be "described" - about the
closest thing that can be done is to list the CID, what checker was
used to detect them (something like "USE_AFTER_FREE" in the case of
CID 10553) and then perhaps what file/function it was found in.
Otherwise, the way the reports are displayed is a code window showing
inline comments about how the checker determined there might be an
issue, and it's not something that can be easily transcribed IMO.
> Of course that would mean I'd need access to Coverity
> which seems fairly difficult...
There are only two primary difficulties:
1) Anyone with access to Haiku's Coverity has the same security
privileges as everyone else who has access. Thus, they have the
ability to mark issue resolutions as "FALSE", "IGNORE", "RESOLVED",
and set the priority, owner, etc. This doesn't really make sense
unless you're a developer actually reviewing and fixing the issue. It
would be nice, however, to have people who triage the issues and
potentially assign them to the appropriate developers.
I don't believe there is any notification system to alert people when
a change to a CID has occurred, so that limits the usefulness of
having anyone other than the developers themselves accessing the
issues. Thus, it has been more or less the policy thus far to limit
Coverity access to those who already have commit access. I don't care
either way - this is more of a policy to decide amongst the developers
- but essentially it would be no different than giving anyone access
to update the status, etc. of our Trac tickets.
2) Getting Coverity to actually add new users has proven to be quite
challenging. Nearly every time I send a request to them, it generally
takes multiple emails over the course of days or weeks before I get a
response.
> And that can stay there, but at least when I see a commit like this:
>
> r39923 /haiku/trunk/src/kits/locale/MutableLocaleRoster.cpp:
>
> Fix CID-10553:
>
> * avoid possible use of deleted catalog (didn't occur because we
>
> currently only have a single type of catalog add-on)
>
> I'll have a clue as to CID-10553 refers to.
Well... theoretically it should be referring to exactly that bug that
was fixed :) (the developer may not always include helpful information
describing the problem)
*How* it refers to the bug is what you're probably curious about I
think - and this is apparently what Coverity wants to limit access to
via their TOS/License Agreement. I wish I could be more helpful - in
the past I requested to possibly setup a readonly account for public
access to Haiku's CIDs and was pretty quickly turned down. Thus, each
person accessing the system must have a separate account and have
agreed to the license terms presented at their first login.
For the most part, what Coverity does is indicate a code path or
potential variable state that violates some check it performs - it's
still mostly up to the developer to determine if that's a problem or
not by reviewing the code in question.
- Urias
Other related posts:
