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

["H. Peter Anvin" <hpa@zytor.com>]

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