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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Thu, 18 Apr 2024, Jan Beulich wrote:
> On 16.04.2024 21:27, Stefano Stabellini wrote:
> > Also add two specific project-wide deviations for R21.6 and R21.15.
> > 
> > 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
> 
> Checking the Misra spec, I'm actually surprised a deviation is needed. The
> rule's rationale talks about streams and file I/O only. Why would the string
> formatting functions be covered then at all? They also don't have, afaik,
> any undefined or implementation defined behavior.

As discussed during the call, I'll add an explanatory note to rules.rst


> > +     - Tagged as `safe` for ECLAIR.
> > +
> > +   * - R21.15
> > +     - The use of void* arguments is justifiable as the rationale for
> > +       the rule is to indicate possible mistakes, and void* is
> > +       frequently used in Xen to represent virtual memory addresses
> 
> But that doesn't rule out mistakes. Are there actually examples in the
> code base?

If you are asking if there are any violations or bugs, I'll defer to the
Bugseng team.

 
> Additionally I wonder (a) whether the rule actually needs an exception

Yes my understanding is that a deviation is necessary from MISRA point
of view, and if nothing else it will serve as extra clarification.


> and thus (b) whether the deviation isn't instead for 21.16. As to (a) I
> understand the rule is worded slightly differently than what would
> strictly be needed to permit void*, but the general rule in C is that
> void* is compatible with all other pointers (suitably qualified as
> needed, of course) anyway.

Roberto and others, can you please confirm whether we need a deviation
on 21.16 as well for similar reasons to 21.15? I am asking because I
don't have any notes about requiring a deviation for 21.16 but I would
like to check with you.