[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


  • To: Xenia Ragiadakou <burzalodowa@xxxxxxxxx>, Julien Grall <julien@xxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Fri, 29 Jul 2022 09:22:39 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=BDMirb63e4mQrLrukOg1fWLmKm00xM0tUHidAUnE5X0=; b=HbN6q9hqF/tLLgBJnOFIgnHhdzOzGuL3dVGy4oLJu0o19Aw6wtdxpRuayko7C7uJmPxmRcWbtRPdBZR+XfVybz1SbIMNMywtAgIirGgk1cHv3Nocjb6Z9TTtYJD1yiMgglMqurIEkeuU88mYVqaf7GN5KrjQOh1d6bJBieXMdHr2ewd5ShqwHmgbYIWI5uy27uAHvPm9SnjUAAYKNReX8GfeaV77hPCmU5Q9iSWjJtRsI9DFtEy/QRFgAmN6U6jKqUzTCo7/l+616GI5pz8eqetmsx6cHPlr+GrGidxfxl88iUSz0p05j83yyVWCNC11njWgaEX9fvSW+9kNN28jMg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Wqg+gETwyaeDg7ara1MCghmL+XIWsoxgW1pKXa9mSpLO/2T2Y07RNRio9XQnlm3IsgHlS+rxVb0rjYYrAMeF7u5aC4R+gixVuHtp8sVfJT1kyIi8s89vejhqjWOy2b6qZCoE2VMQrhMvPYTyKsC66H5VE8AJppHDybzdyp2kStoKEDRPW1G/4oDs6mdzFg7E85qZNXukao0RbxxXKifThYi0A+6CAZV7qv8gu37yGFEVKIav9TlfcVdneQqQ4fAtfwVT/WeWt6gtPC29QRJW6RMpRXd+qafhE9072vW88xDGpVfGPYpzx2oK6v/cHmsSUHD+SO40x4BWO2KVKE1CFQ==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Bertrand Marquis <bertrand.marquis@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx, Stefano Stabellini <sstabellini@xxxxxxxxxx>
  • Delivery-date: Fri, 29 Jul 2022 07:23:04 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

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.

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.)

> 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 ...".

Jan



 


Rackspace

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