Re: 2.6.5-mc2

[Andrew Morton <akpm@osdl.org>]

William Lee Irwin III <wli@holomorphy.com> 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.