Re: [Xen-devel] [PATCH] RFC xen: suppress Coverity warnings about atomic_read and atomic_set.

[Tim Deegan <tim@xxxxxxx>]

At 15:23 +0100 on 12 Sep (1378999422), Tim Deegan wrote:
> At 15:14 +0100 on 12 Sep (1378998843), Ian Campbell wrote:
> > On Thu, 2013-09-12 at 15:06 +0100, Jan Beulich wrote:
> > > >>> On 12.09.13 at 15:47, Tim Deegan <tim@xxxxxxx> wrote:
> > > > RFC because I'm not sure what people think about scattering coverity
> > > > annotations in the code.
> > > 
> > > I personally dislike such tool specific annotations. What if someone
> > > suggests a second tool to pass our code through? If there was
> > > some standardization, that'd be a different thing...
> > 
> > Could we handle this how we do different compilers:
> > 
> > #ifdef COVERITY
> > #define __false_cast_thing THE ANNOTATION
> > #else...
> > 
> > static inline void atomic_set(atomic_t *v, int i)
> > {
> >     __false_cast_thing
> >     write_atomic(&v->counter, i);
> > 
> > Although if the tools are not consistent about placement etc this won't
> > help at all.
> 
> The coverity system seems to be to add a comment immediately above the
> code in question, which seems like it wouldn't play well with macro
> trickery.
> 
> I would prefer, if we can, to either fix this in configuration or get
> coverity fixed to understand the switch(sizeof) trick.

A Coverity engineer has kindly pointed me to the modelling interface,
which I knew we'd have to get into some time.  In particular, this is
python's model: http://hg.python.org/cpython/file/-1/Misc/coverity_model.c

So we can probably sort this out using a model that defines the atomic
r/w ops as straight pointer dereferences.  I'll look at that it I get a
chance.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel