All of lore.kernel.org
 help / color / mirror / Atom feed
From: Federico Serafini <federico.serafini@bugseng.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: consulting@bugseng.com, "Paul Durrant" <paul@xen.org>,
	"Roger Pau Monné" <roger.pau@citrix.com>,
	"Andrew Cooper" <andrew.cooper3@citrix.com>,
	"George Dunlap" <george.dunlap@citrix.com>,
	"Julien Grall" <julien@xen.org>,
	"Stefano Stabellini" <sstabellini@kernel.org>,
	"Wei Liu" <wl@xen.org>,
	xen-devel@lists.xenproject.org
Subject: Re: [XEN RFC] xen: avoid grep fodder define and undef
Date: Tue, 12 Mar 2024 20:54:06 +0100	[thread overview]
Message-ID: <4b62c3e6-0851-4cfe-87ca-06a22d6b8243@bugseng.com> (raw)
In-Reply-To: <338db1b9-54f1-4687-ba9a-2eec282db1d5@suse.com>

On 12/03/24 15:30, Jan Beulich wrote:
> On 12.03.2024 12:48, Federico Serafini wrote:
>> Place an "#if 0" before grep fodder definitions and remove the
>> "#undef".
>>
>> This addresses several violations of MISRA C:2012 Rule 5.5
>> ("Identifiers shall be distinct from macro names").
>>
>> No functional change.
>>
>> Signed-off-by: Federico Serafini <federico.serafini@bugseng.com>
>> ---
>> Hello, I would like to know what you think about this change.
>> If you want to keep grep fodders as they are, an alternative could be to
>> deviate violations of Rule 5.5 involving the TYPE_SAFE macro.
> 
> I think the original intention was to allow for some (arch?) override.
> But we have lived without for long enough that I think we could do as
> you suggest. One question though: Wasn't there also a rule against the
> use of #undef, violations of which would then be eliminate here as well? > If so, I think that would want mentioning in the description. If not,
> I'd like to give it a couple of days before ack-ing, just in case other
> opinions would be voiced.

Yes, it is advisory Rule 20.5.

> 
>> --- a/xen/include/xen/iommu.h
>> +++ b/xen/include/xen/iommu.h
>> @@ -33,13 +33,10 @@ TYPE_SAFE(uint64_t, dfn);
>>   #define PRI_dfn     PRIx64
>>   #define INVALID_DFN _dfn(~0ULL)
>>   
>> -#ifndef dfn_t
>> +#if 0
>>   #define dfn_t /* Grep fodder: dfn_t, _dfn() and dfn_x() are defined above */
>>   #define _dfn
>>   #define dfn_x
>> -#undef dfn_t
>> -#undef _dfn
>> -#undef dfn_x
>>   #endif
> 
> I have to admit that I'm a little surprised that Misra (Eclair) is
> happy with this: The #define-s are all still there, after all.

The #define-s after the #if 0 are skipped by the preprocessor and this
is something that MISRA takes into account.

As an example, Directive 4.4 states that code should not be commented
out and explicitly cites the use of #if and #ifdef to exclude code from
the compilation.

-- 
Federico Serafini, M.Sc.

Software Engineer, BUGSENG (http://bugseng.com)


      reply	other threads:[~2024-03-12 19:54 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-12 11:48 [XEN RFC] xen: avoid grep fodder define and undef Federico Serafini
2024-03-12 14:30 ` Jan Beulich
2024-03-12 19:54   ` Federico Serafini [this message]

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=4b62c3e6-0851-4cfe-87ca-06a22d6b8243@bugseng.com \
    --to=federico.serafini@bugseng.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=consulting@bugseng.com \
    --cc=george.dunlap@citrix.com \
    --cc=jbeulich@suse.com \
    --cc=julien@xen.org \
    --cc=paul@xen.org \
    --cc=roger.pau@citrix.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.