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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Tue, 13 Jun 2023, Jan Beulich wrote:
> On 13.06.2023 05:44, 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, and all explicitly signed integer types.
> 
> If I was to read this without the earlier discussion in mind, I would wonder
> why the unsigned types are explicitly enumerated, but the signed ones are
> described in more general terms. Can't it simply be "all explicitly unsigned
> / signed integer types", which then also covers e.g. uint32_t?

I'll change it to that effect


> > @@ -143,6 +163,32 @@ 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
> > +     - The rule asks that any integer literal that is implicitly
> > +       unsigned is made explicitly unsigned by using one of the
> > +       indicated suffixes.  As an example, on a machine where the int
> > +       type is 32-bit wide, 0x77777777 is signed whereas 0x80000000 is
> > +       (implicitly) unsigned. In order to comply with the rule, the
> > +       latter should be rewritten as either 0x80000000u or 0x80000000U.
> > +       Consistency considerations may suggest using the same suffix even
> > +       when not required by the rule. For instance, if one has:
> > +
> > +       Original: f(0x77777777); f(0x80000000);
> > +
> > +       one might prefer
> > +
> > +       Solution 1: f(0x77777777U); f(0x80000000U);
> > +
> > +       over
> > +
> > +       Solution 2: f(0x77777777); f(0x80000000U);
> > +
> > +       after having ascertained that "Solution 1" is compatible with the
> > +       intended semantics.
> 
> I think we should state here what we want people to do, not what "one
> might prefer". That aspect aside, I'm not convinced the added text
> (matching what Roberto did suggest) really addresses my concerns. Yet
> I'm not going to pursue this any further - we'll see how this ends up
> working in practice.

OK. I'll keep it as is.