Willy Tarreau <[email protected]> wrote:
>
> Thanks Andrew,
>
> I'm very sorry because I have verified the code with gcc-2.95.3,
> gcc-3.3.6 and gcc-3.4.4 on x86 and alpha to ensure that everything
> went smooth on archs where sizeof(long) > sizeof(int). But I've
> tested all the combinations in user-space for obvious ease of
> validation. I believe I forgot to use -Wall. What architecture
> gave you this, and with which compiler please ? I'm willing to
> fix this as soon as I can understand the root of the problem.
>
http://www.zip.com.au/~akpm/linux/patches/stuff/top-posting.txt
>
>
> On Thu, Sep 29, 2005 at 02:43:12AM -0700, Andrew Morton wrote:
> > Willy Tarreau <[email protected]> wrote:
> > >
> > > +#if HZ <= MSEC_PER_SEC && !(MSEC_PER_SEC % HZ)
> > > +# define MAX_MSEC_OFFSET \
> > > + (ULONG_MAX - (MSEC_PER_SEC / HZ) + 1)
> >
> > That generates numbers which don't fit into unsigned ints, yielding vast
> > numbers of
> >
> > include/linux/jiffies.h: In function `msecs_to_jiffies':
> > include/linux/jiffies.h:310: warning: comparison is always false due to limited range of data type
> > include/linux/jiffies.h: In function `usecs_to_jiffies':
> > include/linux/jiffies.h:323: warning: comparison is always false due to limited range of data type
> >
This was a ppc64 build, gcc-3.3.3, CONFIG_HZ=250
Look a the value which MAX_MSEC_OFFSET will take (it's 2^63 minus a bit).
Comparing that to an unsigned int will generate the always-true or
always-false warning.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
|
|