[libvirt] [PATCH (RFC?)] Remove usage of __attribute__((nonnull))

[Daniel P. Berrange]

On Thu, Apr 06, 2017 at 05:40:09PM +0200, Martin Kletzander wrote:
> On Thu, Apr 06, 2017 at 04:27:25PM +0200, Andrea Bolognani wrote:
> > On Wed, 2017-04-05 at 06:53 -0400, John Ferlan wrote:
> > > > I thought that John still had a nightly coverity job running that
> > > > would trigger the -DSTATIC_ANALYSIS codepaths. If that's not the case, then we'd wnat to look
> > > > at enabling that in one of the centos CI jobs.
> > >  
> > > I still have a run of Coverity every night although I have been less
> > > diligent about checking errors lately. Mainly because generally things
> > > that are considered a false positive were being rejected when I posted
> > > patches. I keep about 20 patches in a local branch.
> > >  
> > > There was a point quite a few months ago where my nightly build started
> > > failing because either I changed the Coverity version or the compiler
> > > version on my laptop - cannot recall exactly. That resulted in a bunch
> > > more local patches until I finally had too many and posted that pile
> > > late last month.  Enabling static analysis in CI builds was something I
> > > suggested in my cover - although now I've done it for my every day work
> > > environment so I will see the problems much sooner.
> > 
> > Did we ever get in touch with the Coverity folks about
> > enabling Coverity Scan[1] for libvirt? QEMU is already
> > part of the program.
> > 
> 
> No idea, but we can register there ourselves, can't we?  They have
> integration with GitHub where we have the read-only copy anyway, we can
> even run in on TravisCI and have the whole bundle without changing
> much internally (just committing settings file into the repository).

Yep, I'd be in favour of using the public coverity scan service. For the
sake of community inclusivity / transparency, it is always preferrable to
have project infrastructure visible to the full commnunity where possible.

We could certainly setup a travis CI build too. In particular that would
give us build testing on several versions of Ubuntu, as well as ability
to do OS-X builds which is a notable platform we lack any automated testing
of.

> I think we would get 2 builds per day, depending on how the github repo
> is updated.  Is that done automatically or every X minutes or something?

We only do one build a day right now, so the 2 builds a day limt is no
big deal. Their FAQ is fuzzy on just how builds a triggered...

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://entangle-photo.org       -o-    http://search.cpan.org/~danberr/ :|