Re: [PATCH] docs/misra/rules.rst: add more rules

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Thu, 7 Dec 2023, Jan Beulich wrote:
> On 07.12.2023 03:42, Stefano Stabellini wrote:
> > On Wed, 6 Dec 2023, Jan Beulich wrote:
> >> On 06.12.2023 04:02, Stefano Stabellini wrote:
> >>> --- a/docs/misra/rules.rst
> >>> +++ b/docs/misra/rules.rst
> >>> @@ -462,11 +462,23 @@ maintainers if you want to suggest a change.
> >>>  
> >>>         while(0) and while(1) and alike are allowed.
> >>>  
> >>> +   * - `Rule 16.3 
> >>> <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_16_03.c>`_
> >>> +     - Required
> >>> +     - An unconditional break statement shall terminate every
> >>> +       switch-clause
> >>> +     - In addition to break, also other flow control statements such as
> >>> +       continue, return, goto are allowed.
> >>> +
> >>>     * - `Rule 16.7 
> >>> <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_16_07.c>`_
> >>>       - Required
> >>>       - A switch-expression shall not have essentially Boolean type
> >>>       -
> >>>  
> >>> +   * - `Rule 17.1 
> >>> <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_17_01.c>`_
> >>> +     - Required
> >>> +     - The features of <stdarg.h> shall not be used
> >>> +     -
> >>
> >> Did we really accept this without any constraint (warranting mentioning
> >> here)?
> > 
> > We agreed that in certain situations stdarg.h is OK to use and in those
> > cases we would add a deviation. Would you like me to add something to
> > that effect here? I could do that but it would sound a bit vague.  Also
> > if we want to specify a project-wide deviation it would be better
> > documented in docs/misra/deviations.rst. I would leave Rule 17.1 without
> > a note.
> 
> I can see your point, and I don't have a good suggestion on possible text.
> Still I wouldn't feel well ack-ing this in its present shape.

What about:

     - It is understood that in some limited circumstances <stdarg.h> is
       appropriate to use, such as the implementation of printk. Those
       cases will be dealt with using deviations as usual, see
       docs/misra/deviations.rst and
       docs/misra/documenting-violations.rst.



> >>> @@ -478,12 +490,24 @@ maintainers if you want to suggest a change.
> >>>         have an explicit return statement with an expression
> >>>       -
> >>>  
> >>> +   * - `Rule 17.5 
> >>> <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_17_05.c>`_
> >>> +     - Advisory
> >>> +     - The function argument corresponding to a parameter declared to
> >>> +       have an array type shall have an appropriate number of elements
> >>> +     -
> >>> +
> >>>     * - `Rule 17.6 
> >>> <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_17_06.c>`_
> >>>       - Mandatory
> >>>       - The declaration of an array parameter shall not contain the
> >>>         static keyword between the [ ]
> >>>       -
> >>>  
> >>> +   * - `Rule 17.7 
> >>> <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_17_07.c>`_
> >>> +     - Required
> >>> +     - The value returned by a function having non-void return type
> >>> +       shall be used
> >>> +     -
> >>
> >> Same question here.
> > 
> > Here I was also thinking it might be good to add a comment. Maybe we could
> > add:
> > 
> >      - Please beware that this rule has many violations in the Xen
> >        codebase today, and its adoption is aspirational. However, when
> >        submitting new patches please try to decrease the number of
> >        violations when possible.
> 
> Yea, I think this would be good to add.

I sent out a patch with this addition, and removing Rule 17.1 as that
one is a bit more complicated.