[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2] docs/misra: new rules addition
On 12/06/23 11:50, Jan Beulich wrote:
On 12.06.2023 11:34, Roberto Bagnara wrote:
On 12/06/23 09:33, Jan Beulich wrote:
On 09.06.2023 19:45, Stefano Stabellini wrote:
@@ -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.
I understand this, and ...
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.
... such a note is what my comment was heading towards.
Here is an attempt. "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
f(0x77777777); // Original
f(0x80000000);
one might prefer
f(0x77777777U); // Solution 1
f(0x80000000U);
over
f(0x77777777); // Solution 2
f(0x80000000U);
after having ascertained that "Solution 1" is compatible
with the intended semantics."
@@ -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.
My point is that "not using functions of stdlib.h" is ambiguous: It may
mean functions implemented in an external library (which the hypervisor
doesn't use), or it may mean functions of identical name (and purpose).
The full text goes even further and forbids the use of these
identifiers (plural; see next paragraph), so it's clearly not only
about an external library, and we also can't put it off as inapplicable.
(I wouldn't be surprised if we had a local variable or label named
"exit" or "abort".)
Btw - I can't find a rule 21.21 in my two (slightly different) copies
of the doc, nor one with this headline and a different number. What I
have is "21.8 The Standard Library functions abort, exit and system of
<stdlib.h> shall not be used". (I further wonder why neither of the two
docs allows me to copy-and-paste a line out of it.)
Rule 21.21 was added in MISRA C:2012 Amendment 2, which you can download
(free of charge) from
https://www.misra.org.uk/app/uploads/2021/06/MISRA-C-2012-AMD2.pdf
|
