Hi! > > +#include <asm/bitsperlong.h> > > + > > /* > > - * int-ll64 is used everywhere now. > > + * int-ll64 is used everywhere in kernel now. > > */ > > -#include <asm-generic/int-ll64.h> > > +#if __BITS_PER_LONG == 64 && !defined(__KERNEL__) > > +# include <asm-generic/int-l64.h> > > +#else > > +# include <asm-generic/int-ll64.h> > > +#endif > > I don't think this is correct on all 64-bit architectures, as far as I > remember the > definition can use either 'long' or 'long long' depending on the user space > toolchain. As far as I can tell the userspace bits/types.h does exactly the same check in order to define uint64_t and int64_t, i.e.: #if __WORDSIZE == 64 typedef signed long int __int64_t; typedef unsigned long int __uint64_t; #else __extension__ typedef signed long long int __int64_t; __extension__ typedef unsigned long long int __uint64_t; #endif The macro __WORDSIZE is defined per architecture, and it looks like the defintions in glibc sources in bits/wordsize.h match the uapi asm/bitsperlong.h. But I may have missed something, the code in glibc is not exactly easy to read. > Out of the ten supported 64-bit architectures, there are four that already > use asm-generic/int-l64.h conditionally, and six that don't, and I > think at least > some of those are intentional. > > I think it would be safer to do this one architecture at a time to make > sure this doesn't regress on those that require the int-ll64.h version. I'm still trying to understand what exactly can go wrong here. As long as __BITS_PER_LONG is correctly defined the __u64 and __s64 will be correctly sized as well. The only visible change is that one 'long' is dropped from the type when it's not needed. > There should also be a check for __SANE_USERSPACE_TYPES__ > to let userspace ask for the ll64 version everywhere. That one is easy to fix at least. -- Cyril Hrubis chrubis@xxxxxxx
