All of lore.kernel.org
 help / color / mirror / Atom feed
From: Simon Horman <horms@verge.net.au>
To: Helge Deller <deller@gmx.de>
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:37:40 +0200	[thread overview]
Message-ID: <20191004093737.wftu7iat2gk3abq6@verge.net.au> (raw)
In-Reply-To: <2ac17dd1-99ef-3528-a05e-d51f8af01c95@gmx.de>

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.

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

  reply	other threads:[~2019-10-04  9:37 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 [this message]
2019-10-04  9:51       ` Helge Deller
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=20191004093737.wftu7iat2gk3abq6@verge.net.au \
    --to=horms@verge.net.au \
    --cc=deller@gmx.de \
    --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 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.