Messages in this thread | | | Date | Wed, 7 Apr 2004 11:52:47 -0700 | From | Andrew Morton <> | Subject | Re: 2.6.5-mc2 |
| |
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.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |