Re: docs/misra: add R21.6 R21.14 R21.15 R21.16

[Nicola Vetrini <nicola.vetrini@xxxxxxxxxxx>]

On 2024-04-17 23:13, Stefano Stabellini wrote:
> +Bugseng
>
> On Wed, 17 Apr 2024, Julien Grall wrote:
> > Hi Stefano,
> >
> > On 17/04/2024 20:10, Stefano Stabellini wrote:
> > > On Wed, 17 Apr 2024, Julien Grall wrote:
> > > > Hi Stefano,
> > > >
> > > > On 16/04/2024 20:27, Stefano Stabellini wrote:
> > > > > Also add two specific project-wide deviations for R21.6 and R21.15.
> > > >
> > > > In general, I am fine with add the two rules. However...
> > > >
> > > > >
> > > > > Signed-off-by: Stefano Stabellini <stefano.stabellini@xxxxxxx>
> > > > >
> > > > > diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst
> > > > > index 32b02905d1..9123c8edb5 100644
> > > > > --- a/docs/misra/deviations.rst
> > > > > +++ b/docs/misra/deviations.rst
> > > > > @@ -387,6 +387,22 @@ Deviations related to MISRA C:2012 Rules:
> > > > >           of the Rule due to uses of this macro.
> > > > >         - Tagged as `deliberate` for ECLAIR.
> > > > >    +   * - R21.6
> > > > > +     - The use of snprintf() and vsnprintf() is justifiable as, despite
> > > > > +       the fact that such functions have the same names of the
> > > > > +       corresponding standard library functions, each configuration of
> > > > > +       Xen has a unique implementation for them; the code implementing
> > > > > +       such functions is subject to the analysis, so that any undefined
> > > > > +       or unspecified behavior associated to them falls under the
> > > > > +       responsibility of other MISRA guidelines
> > > > > +     - Tagged as `safe` for ECLAIR.
> > > >
> > > > ... this implies that ECLAIR should be modified. But this is not happening
> > > > in
> > > > this patch. Looking at history, we tend to keep deviations.rst in sync
> > > > with
> > > > ECLAIR, so I think it should be updated here too.
> > >
> > > That is true but I am not very familiar with Eclair config language so
> > > it is better if that is done by the Bugseng team. I can merge their
> > > patch into this one or vice versa or they could be committed separately
> > > (keep in mind that the rule is not enabled in the ECLAIR scan so from a
> > > Gitlab-CI point of view we don't require the change to the ECLAIR config
> > > although it makes sense). I am happy either way.
> >
> > My comment was not about Gitlab CI. It was more about consistency 
> > between the
> > file and ECLAIR. I think they should be kept in sync because it 
> > explain how
> > the tool doing the scanning behave.
> >
> > My preference is to either split and only commit the rules now or wait 
> > for the
> > ECLAIR change to happen.
> Understood. Maybe the Bugseng team can provide the corresponding
> ECLAIR/deviations.ecl changes
Sure, we can respin the patch with the appropriate deviation in place.

--
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)