Re: [RFC 1/7] y2038: Introduce struct __timespec64

[Joseph Myers <joseph at codesourcery dot com>]

On Thu, 28 Mar 2019, Paul Eggert wrote:

> > 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?

I'm suggesting that such structures will end up having contents that 
depend on _TIME_BITS.  What is the Linux kernel using as the 64-bit time 
version of shmid_ds?  Note that the existing padding around the time 
fields there (where present) does *not* generally correspond to 
endianness, i.e. a separate structure layout is needed.

It may well be the case that these headers can and should use the public 
*_t types more.  Historically POSIX didn't always require the *_t types to 
be defined in all headers which had interfaces using them, but they are 
always reserved in POSIX so it's OK to define them anyway in such headers, 
and POSIX has moved towards generally requiring the types to be defined in 
such cases.

> 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.

I don't think we should be particularly concerned by what __* names are 
visible to user code; the visibility of such names is simply a side-effect 
of how the C language works.  They should be present, or not, however is 
convenient for implementing and maintaining the installed headers (which 
includes keeping those headers consistent between different *_t typedefs 
in most cases).

-- 
Joseph S. Myers
joseph@codesourcery.com