Re: [PATCH 00/25] Change time_t and clock_t to 64 bit

H. Peter Anvin
2014-05-17T00:33:32Z

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