[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] RFC xen: suppress Coverity warnings about atomic_read and atomic_set.
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |