Re: [PATCH v2] docs/misra: new rules addition

[Roberto Bagnara <roberto.bagnara@xxxxxxxxxxx>]

On 12/06/23 09:33, Jan Beulich wrote:
> On 09.06.2023 19:45, Stefano Stabellini wrote:
> > @@ -133,6 +146,13 @@ existing codebase are work-in-progress.
> >          headers (xen/include/public/) are allowed to retain longer
> >          identifiers for backward compatibility.
> >   
> > +   * - `Rule 6.1 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_06_01.c>`_
> > +     - Required
> > +     - Bit-fields shall only be declared with an appropriate type
> > +     - In addition to the C99 types, we also consider appropriate types:
> > +       unsigned char, unsigned short, unsigned long, unsigned long long,
> > +       enum.
> What about their signed equivalents? I'm surprised that I found only very
> few uses (in Arm insn decoding afaict), but they generally have a purpose.
> Are the uses we have (and new ones which may appear) intended to become
> deviations?
Explicitly signed integer types are all supported by GCC as well.
So they can be added to the list.

> > @@ -143,6 +163,12 @@ existing codebase are work-in-progress.
> >        - Octal constants shall not be used
> >        -
> >   
> > +   * - `Rule 7.2 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_07_02.c>`_
> > +     - Required
> > +     - A "u" or "U" suffix shall be applied to all integer constants
> > +       that are represented in an unsigned type
> > +     -
> I continue to consider "represented in" problematic here without
> further qualification.
We should distinguish two things here.  The headline of Rule 7.2
is non negotiable: it is simply as it is.  As all headlines,
it is a compromise between conciseness and mnemonic value.
If what is wanted there is not the headline, then you can add
"implicitly" before "represented".  Or you may leave the headline
and add an explanatory note afterwards.

> > @@ -314,6 +340,11 @@ existing codebase are work-in-progress.
> >          used following a subsequent call to the same function
> >        -
> >   
> > +   * - Rule 21.21
> > +     - Required
> > +     - The Standard Library function system of <stdlib.h> shall not be used
> > +     -
> Still no "inapplicable" note (whichever way it would be worded to also
> please Roberto)?
I am not the one to be pleased ;-)

But really, I don't follow: when you say the rule is inapplicable
your reasoning is, IIUC, "nobody would even dream using system() in Xen".
Which is exactly what the rule is asking.  If Xen adopts the rule,
tooling will make sure system() is not used, and seeing that the rule
is applied, assessors will be pleased.