On Thu, 30 Dec 2010, H. Peter Anvin wrote: > On 12/30/2010 02:21 PM, Robert Millan wrote: > > 2010/12/30 Richard Guenther <richard.guent...@gmail.com>: > >> Would be nice if LFS would be mandatory on the new ABI, thus > >> off_t being 64bits. > > > > Please do also consider time_t. > > > > Changing the kernel-facing time_t might completely wreck the reuse of > the i386 kernel ABI; I'm not sure.
Before changing time_t for a new ILP32 ABI, you probably want to work out what is required - on both the libc and kernel sides - to change it for existing 32-bit ABIs (whether providing a new ABI variant like _FILE_OFFSET_BITS does, or changing it unconditionally and using symbol versioning for compatibility with old binaries built for 32-bit time_t). Having done that you then have whatever new syscalls may be needed to work with 64-bit time_t on IA32, and can make the new ILP32 ABI not use the old 32-bit time_t syscalls if desired. Of course making LFS (or 64-bit time_t) mandatory doesn't help with those interfaces that hardcode types such as "int" or "long" - you'll still have code that uses fseek rather than fseeko, for example. If you follow the GNU principles of avoiding arbitrary (or at least inappropriate) limits, there are quite a lot of libc interfaces that can be problematic in extreme cases (large files, strings over 2GB (e.g. regoff_t - glibc bug 5945 - which is probably one of the easier cases), etc.). It would be good to fix these things, both on the GNU principles and for general robustness (there are probably various security holes related to these issues - integer overflow issues are always tricky to avoid in C, but bad choice of types in APIs certainly doesn't help), but it's quite tricky (lots of core ISO C interfaces are involved) and really needs to be kept separate from the introduction of new ABIs at the level of x86_64 ILP32. -- Joseph S. Myers jos...@codesourcery.com