From: Helge Deller <deller@gmx.de>
To: Simon Horman <horms@verge.net.au>
Cc: Sven Schnelle <svens@stackframe.org>, kexec@lists.infradead.org
Subject: Re: [PATCH] kexec-tools: Fix conversion overflow when compiling on 32-bit platforms
Date: Fri, 4 Oct 2019 11:51:05 +0200 [thread overview]
Message-ID: <8157edc8-69cb-33b8-ae1c-7a0d80845c9d@gmx.de> (raw)
In-Reply-To: <20191004093737.wftu7iat2gk3abq6@verge.net.au>
On 04.10.19 11:37, Simon Horman wrote:
> On Thu, Oct 03, 2019 at 10:52:37AM +0200, Helge Deller wrote:
>> On 03.10.19 10:14, Simon Horman wrote:
>>> On Tue, Oct 01, 2019 at 05:14:16PM +0200, Helge Deller wrote:
>>>> When compiling kexec-tools on a 32-bit platform, assigning an
>>>> (unsigned long long) value to an (unsigned long) variable creates
>>>> this warning:
>>>>
>>>> elf_info.c: In function 'read_phys_offset_elf_kcore':
>>>> elf_info.c:805:14: warning: conversion from 'long long unsigned int' to 'long unsigned int' changes value from '18446744073709551615' to '4294967295'
>>>> 805 | *phys_off = UINT64_MAX;
>>>> | ^~~~~~~~~~
>>>>
>>>> Fix it by casting UINT64_MAX to (unsigned long) before storing it to *phys_off.
>>>>
>>>> Signed-off-by: Helge Deller <deller@gmx.de>
>>>>
>>>> diff --git a/util_lib/elf_info.c b/util_lib/elf_info.c
>>>> index 2bce5cb..4d16983 100644
>>>> --- a/util_lib/elf_info.c
>>>> +++ b/util_lib/elf_info.c
>>>> @@ -802,7 +802,7 @@ int read_phys_offset_elf_kcore(int fd, unsigned long *phys_off)
>>>> {
>>>> int ret;
>>>>
>>>> - *phys_off = UINT64_MAX;
>>>> + *phys_off = (unsigned long) UINT64_MAX;
>>>
>>> This seems to mask the problem that UINT64_MAX is not the right
>>> initialiser for unsigned long values on 32-bit platforms.
>>> Could we consider using UINT64_MAX from limits.h instead?
>>
>> UINT64 means it is a 64bit value, while "unsigned long" is either 32-bit,
>> 64bit (or maybe in the future even 128bit?).
>> Even assigning UINT32_MAX on a 32bit platform might be wrong.
>> So I think the cast above is probably the best solution.
>
> Sorry, I made a typo above.
> What I meant is, can we consider using ULONG_MAX.
Yes, that's probably ok.
Helge
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2019-10-04 9:51 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-01 15:14 [PATCH] kexec-tools: Fix conversion overflow when compiling on 32-bit platforms Helge Deller
2019-10-03 8:14 ` Simon Horman
2019-10-03 8:52 ` Helge Deller
2019-10-04 9:37 ` Simon Horman
2019-10-04 9:51 ` Helge Deller [this message]
2019-10-04 10:14 ` Simon Horman
2019-10-04 11:01 ` Helge Deller
2019-10-07 7:12 ` Simon Horman
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=8157edc8-69cb-33b8-ae1c-7a0d80845c9d@gmx.de \
--to=deller@gmx.de \
--cc=horms@verge.net.au \
--cc=kexec@lists.infradead.org \
--cc=svens@stackframe.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox