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

Re: [XEN PATCH 12/13] xen: address violations of MISRA C:2012 Directive 4.10


  • To: Stefano Stabellini <sstabellini@xxxxxxxxxx>, Simone Ballarin <simone.ballarin@xxxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Wed, 6 Sep 2023 08:32:25 +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=nUWmwin3pKqy2LcyeZ6RR9krFaO+29MQUinPN/EI4Ao=; b=UzPM9jCLfFvv47jPnNeoDTbQOPZhsWcfa+x+iLk7WXtBWfRgOe7QQpkU7F5BJ8tXYbgxdfAbh0beqyhwiLVQEExfQ2Xp9cPeuhkyZVKayBfKujvh8bWc1ivUiTPWFdoDbnuTsnFPpTFR+ZORgSRoF02WRGRWmXbfxHfVSOEigpOvlVpNm8v5SoSvjyM1WX8HpeJ0PwMeZ8/kJQ3viSfgwCln56zuIlYsA9vPLeYMfm7ylrRSeuPkpXqadl8HIPr0j+PcOZXOnAjo8Ft6ipxcMAI/p+YBNXA/vz8cHwMsXcfU/U6CEo5Nl45HP1XSspoG1WRMYFQcFp2j8mLkANXwrw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GWjwORNcMoMqdStdALC1AjRJ39xrlI5aJXuA97CqAYe1mj+JB8oYwTRZ9HJA83KylNLlH4ERaoiZJRIjyYc7lTzLzP5E7EJcBynMn2WFOopM3ZNm5PuGxOkQUmZvfvcknHB7ilAxrTYk21YLBqezNRKrqXgKtaS6/gdh2DMGR0+25718u+rwVl8VWHfc3hjRKz6DGPpUbV/YsSbzdLvNPon3or1peScCjlHPXND56pgJaLzuvo+KdhFXD0Xb2WI6FAcmtOF25dc1SDWlyqP4Qt8/FARVKGlF/52nS3jF7HGkCYkVKUM55Md3lcL+NI3PKlNDomsUKD1/UqC6sdluug==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx, consulting@xxxxxxxxxxx, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Wei Liu <wl@xxxxxxx>
  • Delivery-date: Wed, 06 Sep 2023 06:32:35 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 06.09.2023 00:27, Stefano Stabellini wrote:
> On Thu, 31 Aug 2023, Simone Ballarin wrote:
>> On 29/08/23 00:51, Stefano Stabellini wrote:
>>> On Mon, 28 Aug 2023, Simone Ballarin wrote:
>>>> Move or amended inclusion guards to address violations of
>>>> MISRA C:2012 Directive 4.10 ("Precautions shall be taken in order
>>>> to prevent the contents of a header file being included more than
>>>> once").
>>>>
>>>> Inclusion guards must appear at the beginning of the headers
>>>> (comments are permitted anywhere) and the #if directive cannot
>>>> be used for other checks.
>>>>
>>>> Mechanical change.
>>>>
>>>> Signed-off-by: Simone Ballarin <simone.ballarin@xxxxxxxxxxx>
>>>> ---
>>>>   xen/include/xen/err.h       | 4 +++-
>>>>   xen/include/xen/pci_ids.h   | 5 +++++
>>>>   xen/include/xen/softirq.h   | 4 +++-
>>>>   xen/include/xen/unaligned.h | 7 ++++---
>>>>   xen/include/xen/vmap.h      | 4 +++-
>>>>   5 files changed, 18 insertions(+), 6 deletions(-)
>>>>
>>>> diff --git a/xen/include/xen/err.h b/xen/include/xen/err.h
>>>> index 2f29b57d28..a6323d82d7 100644
>>>> --- a/xen/include/xen/err.h
>>>> +++ b/xen/include/xen/err.h
>>>> @@ -1,5 +1,6 @@
>>>> -#if !defined(__XEN_ERR_H__) && !defined(__ASSEMBLY__)
>>>> +#if !defined(__XEN_ERR_H__)
>>>>   #define __XEN_ERR_H__
>>>> +#if !defined(__ASSEMBLY__)
>>>
>>> The original pattern was also guarding the header file sufficiently,
>>> protecting it from double-inclusion. In fact, it is posing stricter
>>> restrictions than usual (not laxer). This change is unnecessary?
>>
>> The MISRA directive asks to use one of the two following forms:
>>
>> <start-of-file>
>> #if !defined ( identifier )
>> #define identifier
>> /* Contents of file */
>> #endif
>> <end-of-file>
>>
>> <start-of-file>
>> #ifndef identifier
>> #define identifier
>> /* Contents of file */
>> #endif
>> <end-of-file>
>>
>> I do not see any reason for deviating, but if you ask that, I can do it.
> 
> Let's follow MISRA's form.

This is what I strongly dislike: They could be less restrictive on the
exact patterns permitted without impacting the goal intended to be
reached. But it's all as simple as possible, not as flexible as possible.

In any event, if a transformation like what can still be seen in context
is to be made, then please #ifdef / #ifndef instead of defined(...)
whenever possible.

Jan



 


Rackspace

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