From: Jan Beulich <jbeulich@suse.com>
To: Stefano Stabellini <sstabellini@kernel.org>,
Simone Ballarin <simone.ballarin@bugseng.com>
Cc: xen-devel@lists.xenproject.org, consulting@bugseng.com,
Andrew Cooper <andrew.cooper3@citrix.com>,
George Dunlap <george.dunlap@citrix.com>,
Julien Grall <julien@xen.org>, Wei Liu <wl@xen.org>
Subject: Re: [XEN PATCH 12/13] xen: address violations of MISRA C:2012 Directive 4.10
Date: Wed, 6 Sep 2023 08:32:25 +0200 [thread overview]
Message-ID: <096eec08-04e4-638f-d250-3a4785a3309d@suse.com> (raw)
In-Reply-To: <alpine.DEB.2.22.394.2309051519270.6458@ubuntu-linux-20-04-desktop>
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@bugseng.com>
>>>> ---
>>>> 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
next prev parent reply other threads:[~2023-09-06 6:32 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-28 13:19 [XEN PATCH 00/13] address violations of MISRA C:2012 Directive 4.10 Simone Ballarin
2023-08-28 13:19 ` [XEN PATCH 01/13] misra: add deviation for headers that explicitly avoid guards Simone Ballarin
2023-08-28 21:59 ` Stefano Stabellini
2023-08-28 22:32 ` Stefano Stabellini
2023-08-30 8:47 ` Simone Ballarin
2023-08-29 6:33 ` Jan Beulich
2023-08-30 8:46 ` Simone Ballarin
2023-08-28 13:19 ` [XEN PATCH 02/13] automation/eclair: add text-based deviation for empty headers Simone Ballarin
2023-08-28 22:00 ` Stefano Stabellini
2023-08-30 10:25 ` Simone Ballarin
2023-08-29 6:35 ` Jan Beulich
2023-08-30 11:27 ` Simone Ballarin
2023-08-28 13:20 ` [XEN PATCH 03/13] xen/arm: address violations of MISRA C:2012 Directive 4.10 Simone Ballarin
2023-08-28 22:02 ` Stefano Stabellini
2023-08-28 22:10 ` Julien Grall
2023-08-30 12:53 ` Simone Ballarin
2023-08-30 13:01 ` Jan Beulich
2023-08-30 13:06 ` Simone Ballarin
2023-08-28 13:20 ` [XEN PATCH 04/13] xen/x86: " Simone Ballarin
2023-08-28 22:11 ` Stefano Stabellini
2023-08-29 13:21 ` Jan Beulich
2023-08-28 13:20 ` [XEN PATCH 05/13] automation/eclair: add deviation for usercopy.c Simone Ballarin
2023-08-28 22:27 ` Stefano Stabellini
2023-08-29 6:41 ` Jan Beulich
2023-08-30 14:47 ` Simone Ballarin
2023-08-31 1:56 ` Stefano Stabellini
2023-08-31 9:24 ` Jan Beulich
2023-09-04 12:43 ` Luca Fancellu
2023-08-28 13:20 ` [XEN PATCH 06/13] x86/EFI: address violations of MISRA C:2012 Directive 4.10 Simone Ballarin
2023-08-28 22:28 ` Stefano Stabellini
2023-08-29 13:27 ` Jan Beulich
2023-08-30 15:16 ` Simone Ballarin
2023-08-28 13:20 ` [XEN PATCH 07/13] x86/asm: " Simone Ballarin
2023-08-28 22:30 ` Stefano Stabellini
2023-08-30 15:23 ` Simone Ballarin
2023-08-29 6:44 ` Jan Beulich
2023-08-28 13:20 ` [XEN PATCH 08/13] x86/mm: " Simone Ballarin
2023-08-28 22:35 ` Stefano Stabellini
2023-08-28 13:20 ` [XEN PATCH 09/13] xen/common: " Simone Ballarin
2023-08-28 22:41 ` Stefano Stabellini
2023-08-29 6:50 ` Jan Beulich
2023-08-31 10:08 ` Simone Ballarin
2023-08-31 11:10 ` Jan Beulich
2023-08-31 12:54 ` Simone Ballarin
2023-08-31 13:05 ` Jan Beulich
2023-08-31 13:30 ` Simone Ballarin
2023-09-05 22:18 ` Stefano Stabellini
2023-09-06 6:28 ` Jan Beulich
2023-09-06 7:35 ` Simone Ballarin
2023-08-28 13:20 ` [XEN PATCH 10/13] xen/efi: " Simone Ballarin
2023-08-28 22:42 ` Stefano Stabellini
2023-08-29 6:47 ` Jan Beulich
2023-08-28 13:20 ` [XEN PATCH 11/13] xen/sched: " Simone Ballarin
2023-08-28 22:43 ` Stefano Stabellini
2023-08-30 14:54 ` George Dunlap
2023-08-28 13:20 ` [XEN PATCH 12/13] xen: " Simone Ballarin
2023-08-28 22:51 ` Stefano Stabellini
2023-08-31 12:18 ` Simone Ballarin
2023-08-31 12:25 ` Jan Beulich
2023-09-05 22:27 ` Stefano Stabellini
2023-09-06 6:32 ` Jan Beulich [this message]
2023-09-07 1:12 ` Stefano Stabellini
2023-08-29 6:54 ` Jan Beulich
2023-08-28 13:20 ` [XEN PATCH 13/13] x86/asm: " Simone Ballarin
2023-08-28 22:45 ` Stefano Stabellini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=096eec08-04e4-638f-d250-3a4785a3309d@suse.com \
--to=jbeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=consulting@bugseng.com \
--cc=george.dunlap@citrix.com \
--cc=julien@xen.org \
--cc=simone.ballarin@bugseng.com \
--cc=sstabellini@kernel.org \
--cc=wl@xen.org \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.