On Sat, 17 May 2014, H. Peter Anvin wrote: > > 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."). > > That is a very different thing, though. It's advising against breaking compatibility with existing applications (in that case, C90 applications that assume sizes can be cast to unsigned long for printing, etc.) unless necessary. Rich Felker suggests <https://sourceware.org/bugzilla/show_bug.cgi?id=16438> there are similar security risks from various types in the x32 ABI being wider than size_t. That seems entirely plausible, if unconfirmed; I don't think there's been much effort to look for such issues where applications expect types to be no wider than size_t when there's no use to them being wider than size_t. Most of those choices are valid but may be risky to existing software much as IL32LLP64 can be risky to existing software. > > 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. > > Given that you already have a long long member of the same structure, it > seems unlikely that adding another long long to this is a problem. > > Anyway, this was discussed back in 2011: > > https://lkml.org/lkml/2011/8/31/244 Just because one buggy port (I consider this quite clearly a bug at the glibc level, whatever the kernel does, agreeing with Rich Felker in <https://sourceware.org/bugzilla/show_bug.cgi?id=16437>) managed to get into glibc does not mean any more should be added. glibc's function is to provide POSIX (and other) interfaces on top of the underlying kernel, which includes fixing any mismatch between the kernel and POSIX interfaces (such as converting from userspace POSIX struct timespec to the form in which times are passed to the kernel, by copying and zeroing padding, if necessary). That's just like implementing POSIX threads on top of clone - or, if future POSIX disallows newlines in filenames (something that's been discussed for some time but doesn't seem to have seen much action lately) but the Linux kernel doesn't follow, making such checks on filenames before passing them to the kernel. Of course, one would hope that the underlying kernel interfaces are designed to make it straightforward to implement POSIX on top of them (as well as other things not envisaged by POSIX). The userspace ABI for struct timespec with 64-bit time_t and 32-bit long should use long tv_nsec in any future ports, with appropriate conversion code in glibc if the kernel interface is different (for ports that started out with 32-bit time_t, conversion code will be needed anyway to convert to the 32-bit structure if the new syscalls are unavailable at runtime and so the old syscalls need to be used, but if the kernel's structure with 64-bit time_t is different from that in userspace then both old and new kernels need conversion code). Given Rich Felker's bug reports, it seems reasonable to suppose that musl will wish to do this as well as glibc. -- 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
