On 05/16/2014 04:47 PM, Joseph S. Myers wrote: >> >> 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. > That is not the issue. The issue is that by fixing the type, the POSIX committee foolishly fixed the ABI unnecessarily. There is nothing wrong with storing this value in a long, of course, but: a) there is no reason it needs to be as wide as long, on an LP64 ABI an int would serve just fine; b) ABI compatibilility issue, especially since on virtually all ABIs a 96-bit struct timespec would end up padded to 128 bits anyway; c) gratuitously different from struct timeval. >> 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."). That is a very different thing, though. > 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 -hpa -- 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
