[RFC 1/7] y2038: Introduce struct __timespec64

[Paul Eggert]

>> However, as long as __time64_t and __time_t are not visible to user
>> code when _TIME_BITS=64, this will address most of my own practical
>> concerns and should be OK as a compromise.
> 
> To sum up:
> ----------
> 
> 1. __time64_t and __time_t are "exported" (visible in /usr/include/*)
> always (similar to __off_t and __off64_t).

No, the compromise is that these types are "exported" only when _TIME_BITS<64. 
Exporting them when _TIME_BITS==64 is unnecessary and confusing. (It's also 
unnecessary and confusing when _TIME_BITS<64, but I'm willing to compromise 
there because the _TIME_BITS<64 case is obsolescent and will eventually go away.)

> 2. The "exported" struct timespec would look like:
> 
> struct timespec
> {
> /* Use the original definition for 64-bit arches
>     or when 64-bit-time by default has *not* been requested */
> #if __WORDSIZE > 32 || ! defined(__USE_TIME_BITS64)
>    __time_t tv_sec; /* Seconds. */
> #else
>    __time64_t tv_sec;
> #end
>    __syscall_slong_t tv_nsec;
> };

Sorry, I'm not following this. Why can't this be the natural 'struct timespec { 
time_t tv_sec; ...; }'? The two forms are equivalent, regardless of whether 
__WORDSIZE > 32 || ! defined(__USE_TIME_BITS64) and regardless of what we do 
about (1), so why use the more-complicated and more-confusing definition?

As Joseph mentioned, there may need to be ifdeffery around tv_nsec due to the 
issue of endian-dependent padding around tv_nsec. However, there does not need 
to be ifdeffery around tv_sec. Just use time_t there; problem solved.

> 3. Put the internal struct __timespec64 ...
> into include/time.h and don't introduce separate
> include/bits/types/struct___timespec64.h
> 
> The same idea would be applied to struct timeval

Yes.