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
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
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.
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
© 2016 - 2024 Red Hat, Inc.