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

Re: [XEN PATCH 2/6] libelf: address MISRA C:2012 Rule 5.3


  • To: Nicola Vetrini <nicola.vetrini@xxxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Mon, 7 Aug 2023 10:11:23 +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=cS4p0fmMuNYoG9ZS2V8EHvpZLTx0RCAzwjtOr9xWwjA=; b=SVUgdZTi7APWsCMCjDtSGevxxUNRcrFy6BGvd94++PddUKl8INkX8UKN1L8MG9E2o/d5vqnP3r7UxoBmdlddRSLHmnXGFn/q076P6aWNCs+QyOErvO56Jt7J3pyfh0T10N+vBfEq/+0rurHoIq65AqFYIQaSHq46+6wJBFa49OJ4SNkC6VXj00OAo15EmUDTUURRSApFy/fkp5GGA19O/foTITRyOODuth7K+93s8w0VBvLQa8Beo9cohVP1v6s8ZAHTsdAmwrxHBAES34vRqW1/WfZ76d/zDsgCh3ls/977ygM6aeubDj5wLm57wgPne9qt4IMBETVbHLAw4BvOlQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FQJ/RJ7IU6Wvx3gsyoy9QrvCqaXMOW9sCPT0LU3ZjVXJsQuGANNz2zS91Q4VNg+xoL4rJHRgJCk+aNb2vlzDrSe9+zhB6jn0mJ7lD0PptTPZsjmFwMpjpa/WvYzEyLn1dnw+GeeRXKhMKKftdRQ+stFIpnrCPND7MJqdAQ4hVPu/QioGBxTRuNAVjJ1sBp6NCmR2hB+WvdPitD0kDLEjnzJQZMgbpGWy3Mdpa3O3RFrOa7gb8e3dDpmVQKOUIA696zhQCoX8dMm2TwcIL5yJ0AlEpFDa5OmUt98nMysk79K1uodVTU+o72+xfNT2aHo8DKrIdPDDS6rbZK6/qTqdAw==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: sstabellini@xxxxxxxxxx, michal.orzel@xxxxxxx, xenia.ragiadakou@xxxxxxx, ayan.kumar.halder@xxxxxxx, consulting@xxxxxxxxxxx, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Wei Liu <wl@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Mon, 07 Aug 2023 08:11:31 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 04.08.2023 17:27, Nicola Vetrini wrote:
> The types u{8,16,32,64} defined in 'xen/arch/x86/include/asm/types.h'
> shadow the variables in the modified function, hence violating Rule 5.3.
> Therefore, the rename takes care of the shadowing.
> 
> No functional changes.
> 
> Signed-off-by: Nicola Vetrini <nicola.vetrini@xxxxxxxxxxx>
> ---
>  xen/common/libelf/libelf-tools.c | 24 ++++++++++++------------
>  1 file changed, 12 insertions(+), 12 deletions(-)
> 
> diff --git a/xen/common/libelf/libelf-tools.c 
> b/xen/common/libelf/libelf-tools.c
> index a9edb6a8dc..f0d5da1abf 100644
> --- a/xen/common/libelf/libelf-tools.c
> +++ b/xen/common/libelf/libelf-tools.c
> @@ -91,10 +91,10 @@ uint64_t elf_access_unsigned(struct elf_binary * elf, 
> elf_ptrval base,
>  {
>      elf_ptrval ptrval = base + moreoffset;
>      bool need_swap = elf_swap(elf);
> -    const uint8_t *u8;
> -    const uint16_t *u16;
> -    const uint32_t *u32;
> -    const uint64_t *u64;
> +    const uint8_t *uint8;
> +    const uint16_t *uint16;
> +    const uint32_t *uint32;
> +    const uint64_t *uint64;

While the chosen names won't collide with stdint.h's, I still consider
them odd. These all being pointers, why not simply pu<N> as names?

Jan



 


Rackspace

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