[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] xen/arm64: sysreg.h: Fix MISRA C 2012 Rule 20.7 violation
On 7/29/22 10:22, Jan Beulich wrote:
On 29.07.2022 09:01, Xenia Ragiadakou wrote:
On 7/29/22 09:16, Jan Beulich wrote:
On 29.07.2022 07:23, Xenia Ragiadakou wrote:
On 7/29/22 01:56, Stefano Stabellini wrote:
On Thu, 28 Jul 2022, Julien Grall wrote:
On 28/07/2022 15:20, Jan Beulich wrote:
On 28.07.2022 15:56, Julien Grall wrote:
On 28/07/2022 14:49, Xenia Ragiadakou wrote:
--- a/xen/arch/arm/include/asm/arm64/sysregs.h
+++ b/xen/arch/arm/include/asm/arm64/sysregs.h
@@ -461,7 +461,7 @@
/* Access to system registers */
#define WRITE_SYSREG64(v, name) do { \
- uint64_t _r = v; \
+ uint64_t _r = (v); \
I am failing to see why the parentheses are necessary here. Could you
give an example where the lack of them would end up to different code?
I think it is merely good practice to parenthesize the right sides of =.
Indeed with assignment operators having second to lowest precedence, and
with comma (the lowest precedence one) requiring parenthesization at the
macro invocation site, there should be no real need for parentheses here.
I am not really happy with adding those parentheses because they are
pointless. But if there are a consensus to use it, then the commit message
should be updated to clarify this is just here to please MISRA (to me "need"
implies it would be bug).
Let me premise that I don't know if this counts as a MISRA violation or
not. (Also I haven't checked if cppcheck/eclair report it as violation.)
But I think the reason for making the change would be to follow our
coding style / coding practices. It makes the code simpler to figure out
that it is correct, to review and maintain if we always add the
parenthesis even in cases like this one where they are not strictly
necessary. We are going to save our future selves some mental cycles.
So the explanation on the commit message could be along those lines.
First, the rule 20.7 states "Expressions resulting from the expansion of
macro parameters shall
be enclosed in parentheses". So, here it is a clear violation of the
rule because the right side of the assignment operator is an expression.
Second, as I stated in a previous email, if v is not enclosed in
parentheses, I could write the story of my life in there and compile it
:) So, it would be a bug.
So, I recommend the title and the explanation i.e
"xen/arm64: sysreg.h: Fix MISRA C 2012 Rule 20.7 violation
The macro parameter 'v' is used as an expression and needs to be enclosed in
parentheses."
to remain as is because they are accurate.
I'm afraid you're following the MISRA wording too much to the latter.
Earlier on you agreed that when macro parameters are used as function
arguments, the parentheses can be omitted. Yet by what you say above
those are also expressions.
Yes, those are also expressions (that's why I added parentheses
initially) and I agreed with you that the parentheses there may not be
necessary because I could not think of an example that will produce
different behaviors with and without the parentheses. This will need a
formal deviation I imagine or maybe a MISRA C expert could provide a
justification regarding why parentheses are needed around function
arguments that we may have not think of.
As indicated before - I think parentheses
are wanted here, but it's strictly "wanted", and hence the title
better wouldn't say "fix" (but e.g. "improve") and the description
also should be "softened".
Regarding the latter, are you saying that the parentheses are not needed?
In my opinion they are needed to prevent the bug described in the
previous email i.e passing multiple statements to the macro.
Any such use would be rejected during review, I'm sure.
I would argue that any such use should be rejected by the compiler.
However I think there's another case which might indeed make this
more than just a "want" (and then responses further down are to be
viewed only in the context of earlier discussion):
#define wr(v) ({ \
unsigned r_ = v; \
asm("" :: "r" (r_)); \
})
#define M x, y
void test(unsigned x) {
wr(M);
}
While this would result in an unused variable warning, it's surely
misleading (and less certain to be noticed during review) - which
is what Misra wants to avoid. Let's see what Julien thinks.
By whom are they wanted? I 'm afraid I cannot understand.
By us as a community: This can be viewed as one of many agreements we
have on coding style. (As such it may want to be written down somewhere.)
In that case, first it should be mentioned in the coding style document
and then make reference to it in commit messages.
Also, are you proposing to change the title into "Improve MISRA C 2012
Rule 20.7 violation" ?
Obviously not. I was thinking of "improve to avoid ...".
--
Xenia
|
