[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



Hi Stefano,

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.

Xenia



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.