[PATCH] docs/misra: replace R13.1 with R13.2

Stefano Stabellini posted 1 patch 6 months, 2 weeks ago
Failed in applying to current master (apply log)
[PATCH] docs/misra: replace R13.1 with R13.2
Posted by Stefano Stabellini 6 months, 2 weeks ago
After looking closely at the R13.1 violations and potential fixes or
deviations, upon further reflection and discussions, we realized that it
is R13.2, limited to initializers list, that we want to comply with.

Link: https://marc.info/?l=xen-devel&m=170751643325805
Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>

diff --git a/docs/misra/rules.rst b/docs/misra/rules.rst
index d3b70fdf04..c02dea9af8 100644
--- a/docs/misra/rules.rst
+++ b/docs/misra/rules.rst
@@ -449,10 +449,11 @@ maintainers if you want to suggest a change.
        parameter declared as "array of type"
      -
 
-   * - `Rule 13.1 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_13_01_1.c>`_
+   * - `Rule 13.2 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_13_02.c>`_
      - Required
-     - Initializer lists shall not contain persistent side effects
-     -
+     - The value of an expression and its persistent side-effects shall
+       be the same under all permitted evaluation orders
+     - Limit the scope of this rule to initializer lists
 
    * - `Rule 13.6 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_13_06.c>`_
      - Required
Re: [PATCH] docs/misra: replace R13.1 with R13.2
Posted by Jan Beulich 6 months, 2 weeks ago
On 11.05.2024 01:32, Stefano Stabellini wrote:
> After looking closely at the R13.1 violations and potential fixes or
> deviations, upon further reflection and discussions, we realized that it
> is R13.2, limited to initializers list, that we want to comply with.
> 
> Link: https://marc.info/?l=xen-devel&m=170751643325805

The mail you point at is a reply to one where I raised an aspect that was
never really addressed: 'I'm afraid I don't understand the "eventually
limiting" part.' Therefore I also don't follow why we'd want to limit
applicability of this rule to just initializer lists. I'm pretty sure we
do not want expressions the result of which or any side effects of which
are unpredictable, no matter where such an expression is used.

Jan
Re: [PATCH] docs/misra: replace R13.1 with R13.2
Posted by Stefano Stabellini 6 months, 2 weeks ago
On Tue, 14 May 2024, Jan Beulich wrote:
> On 11.05.2024 01:32, Stefano Stabellini wrote:
> > After looking closely at the R13.1 violations and potential fixes or
> > deviations, upon further reflection and discussions, we realized that it
> > is R13.2, limited to initializers list, that we want to comply with.
> > 
> > Link: https://marc.info/?l=xen-devel&m=170751643325805
> 
> The mail you point at is a reply to one where I raised an aspect that was
> never really addressed: 'I'm afraid I don't understand the "eventually
> limiting" part.' Therefore I also don't follow why we'd want to limit
> applicability of this rule to just initializer lists.

I was trying to make a 1:1 replacement, but I see your point and I
agree. We'll have to discuss at the next MISRA C meeting whether to
accept R13.2 in full or partially.
Re: [PATCH] docs/misra: replace R13.1 with R13.2
Posted by Jan Beulich 6 months, 2 weeks ago
On 14.05.2024 15:47, Jan Beulich wrote:
> On 11.05.2024 01:32, Stefano Stabellini wrote:
>> After looking closely at the R13.1 violations and potential fixes or
>> deviations, upon further reflection and discussions, we realized that it
>> is R13.2, limited to initializers list, that we want to comply with.
>>
>> Link: https://marc.info/?l=xen-devel&m=170751643325805
> 
> The mail you point at is a reply to one where I raised an aspect that was
> never really addressed: 'I'm afraid I don't understand the "eventually
> limiting" part.' Therefore I also don't follow why we'd want to limit
> applicability of this rule to just initializer lists. I'm pretty sure we
> do not want expressions the result of which or any side effects of which
> are unpredictable, no matter where such an expression is used.

Oh, and a formal aspect: I don't think an initializer list counts as
expression. Instead it's a construct involving multiple expressions,
evaluation order of which is unspecified. Specifically

unsigned arr[2] = { i++, i++ };

would violate 13.1 but satisfy 13.2, because 13.2 is concerned of
only each individual expression (and this isn't a comma expression
but a list, somewhat similar to argument lists in function calls).

Surely the compiler would already choke on this, but I wanted to use
a simple example.

Jan