Re: 2.6.5-mc2

From: Andrew Morton
Date: Wed Apr 07 2004 - 13:52:52 EST


William Lee Irwin III <wli@xxxxxxxxxxxxxx> wrote:
>
> On Wed, Apr 07, 2004 at 11:27:38AM -0700, Andrew Morton wrote:
> > I did it this way, relying on magical promotions:
> > --- 25/fs/open.c~nfs-32bit-statfs-fix-warning-fix 2004-04-06 23:16:25.221685072 -0700
> > +++ 25-akpm/fs/open.c 2004-04-06 23:16:25.225684464 -0700
> > @@ -64,10 +64,10 @@ static int vfs_statfs_native(struct supe
> > * f_files and f_ffree may be -1; it's okay to stuff
> > * that into 32 bits
> > */
> > - if (st.f_files != 0xffffffffffffffffULL &&
> > + if (st.f_files != -1 &&
> > (st.f_files & 0xffffffff00000000ULL))
> > return -EOVERFLOW;
> > - if (st.f_ffree != 0xffffffffffffffffULL &&
> > + if (st.f_ffree != -1 &&
> > (st.f_ffree & 0xffffffff00000000ULL))
>
> Are you sure this works? IIRC -1 is promoted only afterward, yielding
> on 64-bit (1UL << 32) - 1 instead of ~0UL, which was the issue with
> init_task.cpus_allowed being initialized to -1 on 2.4.x. Maybe it's
> better behaved in this instance (language lawyer territory).


This says yes:

main()
{
unsigned long long ll = 0xffffffffffffffff;

if (ll == -1)
printf("yes\n");
}

The compiler has ((int)-1) and then has to promote it to ULL. If it does
the conversion to unsigned before the conversion to long long, we lose.
But it doesn't, and I couldn't immediately find a spec which justfies this
behaviour.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/