On 07/08/2023 10:11, Jan Beulich wrote:
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.vetr...@bugseng.com>
---
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
lgtm.
--
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)
