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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

+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