[RFC 1/7] y2038: Introduce struct __timespec64

[Paul Eggert]

On 3/28/19 9:39 AM, Joseph Myers wrote:
>
> having __time_t handled differently from __off_t in that 
> regard (by making the definition depend on _TIME_BITS, rather than only 
> having the definition of time_t depend on _TIME_BITS) would be liable to 
> confuse people reading glibc headers.

It depends on what sort of confusion is more likely to cause trouble.
I'm worried about confusion in user code mistakenly using __time64_t -
something that *will* happen, I'm afraid (we've seen that with
__off64_t). The confusion you're worried about would be limited to
people reading glibc source code (i.e., code not installed under
/usr/include) and so it is considerably more limited in scope and can be
addressed by a comment as needed.


> It's more plausible that the headers should not define __time_t at all in 
> the _TIME_BITS=64 case (if there are no interfaces that would use it).
>
Several installed .h files use __time_t now, e.g., <bits/shm.h>. Are you
suggesting that it's plausible to change them to use time_t instead?
Something like this should work, yes. But then when _TIME_BITS=64 public
headers won't need to define __time64_t either, for the same reason they
won't need to define __time_t. I.e., if _TIME_BITS=64 then neither
__time_t nor __time64_t would be defined.

That would be OK for me (as I intend to use _TIME_BITS=64 in all my
apps, and by 2038 _TIME_BITS=64 will be the default). However, I'm still
puzzled as to why glibc should expose __time_t and __time64_t to
_TIME_BITS!=64 user code, given that we don't want to support mixed-mode
user code.