Re: [XEN PATCH] xen: Add SAF deviations for MISRA C:2012 Rule 7.1

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Wed, 11 Oct 2023, Julien Grall wrote:
> On 11/10/2023 11:53, Luca Fancellu wrote:
> > 
> > > > > 
> > > > > Luca answered to a similar, more generic, question a few days ago
> > > > > about
> > > > > Coverity: https://marc.info/?l=xen-devel&m=169657904027210
> > > > Interesting.
> > > > > 
> > > > > So even if we get cppcheck to work like that, we would lose Coverity
> > > > > support.
> > > > I think my suggestion was probably misunderstood. So let me clarify it.
> > > > To cover multi-line, we could write the following in Xen:
> > > > /* cppcheck tag next-3-lines */
> > > > line 1
> > > > line 2
> > > > line 3
> > > > AFAIU Eclair supports multi-line, so the tag would be transformed to
> > > > there internal solution. For CPPCheck, this could be transformed to:
> > > > /* cppcheck tag next-3 lines */
> > > > line 1 /* generated cppcheck tag */
> > > > line 2 /* generated cppcheck tag */
> > > > line 3 /* generated cppcheck tag */
> > > > Now, I understand that coverity doesn't support any of the two format.
> > > > So the only solution would be to add the comment before each line which
> > > > would impact the line numbers. This is not great, but I think this is
> > > > acceptable as the context would likely help to find where this is coming
> > > > from.
> > > 
> > > Just to clarify, here I meant that for coverity, a script before the scan
> > > could convert to the multi-line version. So the line change only impact
> > > Coverity.
> > 
> > Hi Julien,
> > 
> > We’ve tried to avoid that because when the tool insert lines, the resultant
> > report would give wrong lines numbers if any violation is reported after the
> > insertion points. So there will be a mismatch between the codebase and the
> > report findings from some point on in the file.
> 
> I know. Stefano already pointed that out. But as I wrote, I don't think this
> is a big problem as it only affecte one tool (Coverity) and one would still be
> able to find the exact place based on the context.

Yeah I think we could consider going that way if it only affects 1 tool
out of 3.

We might still have to patch cppcheck to add the functionality but it
might not be that difficult.