[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [XEN PATCH] xen: fix violations of MISRA C:2012 Rule 3.1


  • To: Nicola Vetrini <nicola.vetrini@xxxxxxxxxxx>
  • From: Luca Fancellu <Luca.Fancellu@xxxxxxx>
  • Date: Wed, 12 Jul 2023 16:36:18 +0000
  • Accept-language: en-GB, en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.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=VQkI+Bitb+JFnJYSvA/ti/6vfRy6Yy3MkNNTQHFyjYI=; b=hKWwYo2zUEWsCWO1RIGZKh8teEG2idnKrX5Q9P9Yaf4QFksqOr0unU2DFNPALgF7INn1FJsuGWM6tsQx5kXLcvSRql/3ykJLxv2yZDXCfvzmip3v2u8cCakv2B2B6xZ6BWrJOATW7vX+M1qynQei+XEaNzID9kfsTW8rg/pTRgzBHCY/u/tJ3gR+f0x1tDKvowovEOxvfHqNulUzL45N38ZbGzjrN4L7dLNiKS/B7bdXjRkwfnJOtXDYxHFQ0HuuznueIhHRyL4uM+RYmNyLpvjZ86LMCh2E7YEhzf+VP2lLFE4GFzoUvsq55imQ7Cn4FO5VV3l3jWz8kFGJvqcXjA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XDJStZd3RixbA3egb4O8+C9dOkFf+MrcaIJQjCbYb8Ni0AV1m0Jg1d476koUg66CrdpjZN1rM0NucLNh0NknggKokFpMddOiWtST+BVQKQqOaNNiZsBI21hpybLldaJDaF1201TA9Uo7FkwGf48gjuDndpopuPX2PtM+xpASXcN+TdDYRgGrn5sWSBtCIpnnRz+2O3+5UcaJ1Ejx9kolehxKlx1Or7f8PvLnHZlDfbjK/DK6nEaV0DhH+9czDNEdlExHUCzSldFWAAdpUw1B6c/J2cHV4rOMjU3qZ4gWjH2/rzQJslfM1JHvhcUqqUAQV8HGa6Z3Ux7IuT9R8KJwXg==
  • Authentication-results-original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com;
  • Cc: Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, "michal.orzel@xxxxxxx" <michal.orzel@xxxxxxx>, "xenia.ragiadakou@xxxxxxx" <xenia.ragiadakou@xxxxxxx>, "ayan.kumar.halder@xxxxxxx" <ayan.kumar.halder@xxxxxxx>, "consulting@xxxxxxxxxxx" <consulting@xxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>, Julien Grall <julien@xxxxxxx>, Wei Liu <wl@xxxxxxx>
  • Delivery-date: Wed, 12 Jul 2023 16:37:22 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Nodisclaimer: true
  • Original-authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com;
  • Thread-index: AQHZtNlJBMaqjD35lk+am0TGpnL30K+2StiAgAAEHQCAAAVDAA==
  • Thread-topic: [XEN PATCH] xen: fix violations of MISRA C:2012 Rule 3.1


> On 12 Jul 2023, at 17:17, Nicola Vetrini <nicola.vetrini@xxxxxxxxxxx> wrote:
> 
> 
> 
> On 12/07/23 18:02, Luca Fancellu wrote:
>>> On 12 Jul 2023, at 16:54, Nicola Vetrini <nicola.vetrini@xxxxxxxxxxx> wrote:
>>> 
>>> In the file 'xen/common/xmalloc_tlsf.c' is not clear how
>>> the commented-out code should interact with the previous statement.
>>> To resolve the MISRA violation generated by the nested comment
>>> a #if .. #endif block with an explanatory comment substitutes
>>> the earlier construct.
>>> 
>>> In the file 'xen/include/xen/atomic.h' the nested comment has been removed,
>>> since the code sample is already explained by the preceding comment.
>>> 
>>> Signed-off-by: Nicola Vetrini <nicola.vetrini@xxxxxxxxxxx>
>>> ---
>>> Following the suggestion of this message
>>> https://lore.kernel.org/xen-devel/536f3049-41f7-b127-ba94-81925e34ea0f@xxxxxxxx/
>>> an explanatory comment has been added.
>>> ---
>>> xen/common/xmalloc_tlsf.c | 13 ++++++++++---
>>> xen/include/xen/atomic.h  |  2 +-
>>> 2 files changed, 11 insertions(+), 4 deletions(-)
>>> 
>>> diff --git a/xen/common/xmalloc_tlsf.c b/xen/common/xmalloc_tlsf.c
>>> index c21bf71e88..56c3849414 100644
>>> --- a/xen/common/xmalloc_tlsf.c
>>> +++ b/xen/common/xmalloc_tlsf.c
>>> @@ -139,10 +139,17 @@ static inline void MAPPING_SEARCH(unsigned long *r, 
>>> int *fl, int *sl)
>>>         *r = *r + t;
>>>         *fl = flsl(*r) - 1;
>>>         *sl = (*r >> (*fl - MAX_LOG2_SLI)) - MAX_SLI;
>>> -        *fl -= FLI_OFFSET;
>>> -        /*if ((*fl -= FLI_OFFSET) < 0) // FL will be always >0!
>>> -         *fl = *sl = 0;
>>> +        /*
>>> +         * It's unclear what was the purpose of the commented-out code 
>>> that now
>>> +         * is in the #else branch. The current form is motivated by the 
>>> correction
>>> +         * of a violation MISRA:C 2012 Rule 3.1
>>>          */
>>> +#if 1
>>> +        *fl -= FLI_OFFSET;
>>> +#else
>>> +        if ((*fl -= FLI_OFFSET) < 0) // FL will be always >0!
>> In the message you linked above, you suggested to use /* FL will be always 
>> >0! */, why has it changed?
>> Was some comment I missed? The xen codestyle mandates the use of /* */, 
>> anyway I agree that here you
>> are just moving code...
>> So maybe the maintainer can tell what is the best thing to do here.
> 
> You didn't miss any further comment: my suggestion was related to the 
> explanatory comment, not the nested comment itself. If a better wording can 
> be found for the former, no problem. As for the codestyle point: it does not 
> change anything doing
> "// FL will be always >0!" -> "/* FL will be always >0!  */
> w.r.t. Rule 3.1 (both would have been nested comments).

Yes, I agree it does not change anything, now that I read better the message, 
it is from Jan suggesting this:

#if 1
    *fl -= FLI_OFFSET;
#else
    if ((*fl -= FLI_OFFSET) < 0) /* FL will be always >0! */
        *fl = *sl = 0;
#endif

So using /* FL will be always >0! */ instead of copying // FL will be always >0!

Anyway, I think it can be addressed on commit, whatever form the maintainer 
prefers.

> 
> Regards,
> 
> -- 
> Nicola Vetrini, BSc
> Software Engineer, BUGSENG srl (https://bugseng.com)




 


Rackspace

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