[XEN PATCH 06/13] xen/mem_access: address violations of MISRA C:2012 Rule 7.3

Simone Ballarin posted 13 patches 2 years, 6 months ago
[XEN PATCH 06/13] xen/mem_access: address violations of MISRA C:2012 Rule 7.3
Posted by Simone Ballarin 2 years, 6 months ago
From: Gianluca Luparini <gianluca.luparini@bugseng.com>

The xen sources contain violations of MISRA C:2012 Rule 7.3 whose headline
states:
"The lowercase character 'l' shall not be used in a literal suffix".

Use the "L" suffix instead of the "l" suffix, to avoid potential ambiguity.
If the "u" suffix is used near "L", use the "U" suffix instead, for consistency.

The changes in this patch are mechanical.

Signed-off-by: Gianluca Luparini <gianluca.luparini@bugseng.com>
Signed-off-by: Simone Ballarin <simone.ballarin@bugseng.com>
---
 xen/common/mem_access.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/common/mem_access.c b/xen/common/mem_access.c
index 010e6f8dbf..385950789c 100644
--- a/xen/common/mem_access.c
+++ b/xen/common/mem_access.c
@@ -60,7 +60,7 @@ int mem_access_memop(unsigned long cmd,
 
     case XENMEM_access_op_set_access:
         rc = -EINVAL;
-        if ( (mao.pfn != ~0ull) &&
+        if ( (mao.pfn != ~0ULL) &&
              (mao.nr < start_iter ||
               ((mao.pfn + mao.nr - 1) < mao.pfn) ||
               ((mao.pfn + mao.nr - 1) > domain_get_maximum_gpfn(d))) )
@@ -96,7 +96,7 @@ int mem_access_memop(unsigned long cmd,
             break;
 
         rc = -EINVAL;
-        if ( (mao.pfn > domain_get_maximum_gpfn(d)) && mao.pfn != ~0ull )
+        if ( (mao.pfn > domain_get_maximum_gpfn(d)) && mao.pfn != ~0ULL )
             break;
 
         rc = p2m_get_mem_access(d, _gfn(mao.pfn), &access, 0);
-- 
2.34.1
Re: [XEN PATCH 06/13] xen/mem_access: address violations of MISRA C:2012 Rule 7.3
Posted by Stefano Stabellini 2 years, 6 months ago
On Thu, 3 Aug 2023, Simone Ballarin wrote:
> From: Gianluca Luparini <gianluca.luparini@bugseng.com>
> 
> The xen sources contain violations of MISRA C:2012 Rule 7.3 whose headline
> states:
> "The lowercase character 'l' shall not be used in a literal suffix".
> 
> Use the "L" suffix instead of the "l" suffix, to avoid potential ambiguity.
> If the "u" suffix is used near "L", use the "U" suffix instead, for consistency.
> 
> The changes in this patch are mechanical.
> 
> Signed-off-by: Gianluca Luparini <gianluca.luparini@bugseng.com>
> Signed-off-by: Simone Ballarin <simone.ballarin@bugseng.com>

Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Re: [XEN PATCH 06/13] xen/mem_access: address violations of MISRA C:2012 Rule 7.3
Posted by Jan Beulich 2 years, 5 months ago
On 04.08.2023 02:47, Stefano Stabellini wrote:
> On Thu, 3 Aug 2023, Simone Ballarin wrote:
>> From: Gianluca Luparini <gianluca.luparini@bugseng.com>
>>
>> The xen sources contain violations of MISRA C:2012 Rule 7.3 whose headline
>> states:
>> "The lowercase character 'l' shall not be used in a literal suffix".
>>
>> Use the "L" suffix instead of the "l" suffix, to avoid potential ambiguity.
>> If the "u" suffix is used near "L", use the "U" suffix instead, for consistency.
>>
>> The changes in this patch are mechanical.
>>
>> Signed-off-by: Gianluca Luparini <gianluca.luparini@bugseng.com>
>> Signed-off-by: Simone Ballarin <simone.ballarin@bugseng.com>
> 
> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>

I notice this again was committed with an ack by Tamas which has never appeared
on list. At that time I pointed out that the reason may have been connected to
the mail (as you had forwarded) having been a HTML one.

Yet then looks like the same has happened to me, with "Re: Ping: [PATCH]
mem-sharing: move (x86) / drop (Arm) arch_dump_shared_mem_info()". I can't find
record of this in the list archive. And that mail, from all I can tell, was a
plain text one.

George, for the earlier instance Stefano had Cc-ed you, apparently on the
assumption that you might be able to do something about this, or initiate that
something be done. Is there anything that was found out? Just in case I'll
attach the mail I did receive.

I also wonder what other mails from you, Tamas, may not have appeared on list,
and instead were (presumably) only delivered to people explicitly Cc-ed.

Jan> > When !MEM_SHARING no useful output is produced. Move the function into
> > mm/mem_sharing.c while conditionalizing the call to it, thus allowing to
> > drop it altogether from Arm (and eliminating the need to introduce stubs
> > on PPC and RISC-V).
> >
> > Signed-off-by: Jan Beulich <jbeulich@suse.com>
>
> Tamas - any chance of an ack?

Acked-by: Tamas K Lengyel <tamas@tklengyel.com>
Re: [XEN PATCH 06/13] xen/mem_access: address violations of MISRA C:2012 Rule 7.3
Posted by Stefano Stabellini 2 years, 5 months ago
Tamas, is it possible that you are not actually subscribed to xen-devel
with your email tamas@tklengyel.com  ?

Sorry for top-posting I wanted to make sure Tamas saw this.


On Thu, 24 Aug 2023, Jan Beulich wrote:
> On 04.08.2023 02:47, Stefano Stabellini wrote:
> > On Thu, 3 Aug 2023, Simone Ballarin wrote:
> >> From: Gianluca Luparini <gianluca.luparini@bugseng.com>
> >>
> >> The xen sources contain violations of MISRA C:2012 Rule 7.3 whose headline
> >> states:
> >> "The lowercase character 'l' shall not be used in a literal suffix".
> >>
> >> Use the "L" suffix instead of the "l" suffix, to avoid potential ambiguity.
> >> If the "u" suffix is used near "L", use the "U" suffix instead, for consistency.
> >>
> >> The changes in this patch are mechanical.
> >>
> >> Signed-off-by: Gianluca Luparini <gianluca.luparini@bugseng.com>
> >> Signed-off-by: Simone Ballarin <simone.ballarin@bugseng.com>
> > 
> > Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
> 
> I notice this again was committed with an ack by Tamas which has never appeared
> on list. At that time I pointed out that the reason may have been connected to
> the mail (as you had forwarded) having been a HTML one.
> 
> Yet then looks like the same has happened to me, with "Re: Ping: [PATCH]
> mem-sharing: move (x86) / drop (Arm) arch_dump_shared_mem_info()". I can't find
> record of this in the list archive. And that mail, from all I can tell, was a
> plain text one.
> 
> George, for the earlier instance Stefano had Cc-ed you, apparently on the
> assumption that you might be able to do something about this, or initiate that
> something be done. Is there anything that was found out? Just in case I'll
> attach the mail I did receive.
> 
> I also wonder what other mails from you, Tamas, may not have appeared on list,
> and instead were (presumably) only delivered to people explicitly Cc-ed.