On Sat, 17 May 2014, H. Peter Anvin wrote: > On 05/15/2014 01:38 PM, Arnd Bergmann wrote: > > > > For practical purposes in the kernel, we may still want to use 64-bit > > nanoseconds: if we use a 96 bit struct timespec, that would be incompatible > > with the native type on 64-bit kernels, thus complicating the syscall > > emulation layer. > > > > I don't know why timespec on x32 uses 'long tv_nsec', it does seem > > problematic. > > struct timespec is specified in POSIX as having type "long" for tv_nsec. > This, as Linus pointed out, is totally braindamaged. long is a perfectly reasonable type for this purpose - it's guaranteed to have enough precision. ISO C11 follows POSIX in the definition of struct timespec. > x32 does not follow POSIX (Linus pretty much dictated that), and instead > does the __kernel_suseconds_t to match the native kernel type. The > proposal at some point was to try to push a snseconds_t into POSIX. If the x32 kernel won't be fixed to treat the high part as padding then glibc will need fixing to copy all struct timespec values passed to the kernel and clear the padding when copying (really, fixing that bug would need such copying anyway unless --enable-kernel is used to allow a fixed kernel to be assumed). In any case, we should not put any more ports into glibc with that x32 bug; "long" and an explicit padding field is the way to go (and copying / zeroing if the kernel doesn't treat that padding field as padding). Adding snseconds_t to POSIX seems pointless when there is no need for this field to store values that can't fit in "long". Even if it were added, good practice would say that implementations should keep using "long" whenever possible for compatibility with existing applications (just like the ISO C recommendation "The types used for size_t and ptrdiff_t should not have an integer conversion rank greater than that of signed long int unless the implementation supports objects large enough to make this necessary."). If you were designing from scratch, no doubt a typedef such as snseconds_t would be there, but with real-world APIs that have accumulated over time, deviating from "long" now is a bad idea. -- Joseph S. Myers joseph@xxxxxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html