[RFC v6 04/23] linux: Use 32-bit time_t for itimerval

[Alistair Francis]

On Thu, Jan 16, 2020 at 11:21 AM Joseph Myers <joseph@codesourcery.com> wrote:
>
> On Thu, 16 Jan 2020, Alistair Francis wrote:
>
> > > To allow it this syscall wrapper shall be converted (written) in the
> > > same way as e.g:
> > >
> > > ./sysdeps/unix/sysv/linux/clock_settime.c
> > >
> > > (the same issue is with getitimer).
> > >
> > > Then only redirection when __USE_TIME_BITS64 is set are needed to use
> > > __setitimer64/__getitimer64 on Y2038 safe systems.
> >
> > I'm not sure what you mean here.
> >
> > There is no setitimer64/getitimer64 syscall so we need to make sure we
> > pass a 32-bit time_t here. If __TIMESIZE == 32 then we don't need any
> > changes and can just directly make the syscall (as we do in this
> > patch). The conversion is only required if __TIMESIZE == 64 as we need
> > to convert to/from a 32-bit time_t.
>
> This is a point about the general structure and goals of the Y2038 work.
>
> We want to end up at a point where, on systems where time_t is currently
> 32-bit, you can build with -D_TIME_BITS=64 and get 64-bit time_t instead.
> That means that all time-related functions, including getitimer and
> setitimer, will, on such systems, need to have two implementations in
> glibc, one using 64-bit times and one using 32-bit times.

I'm still confused. If we build with -D_TIME_BITS=64 does that then
mean that __TIMESIZE == 64 ?

In which case the user exposed time_t is 64-bit and these calls will
take a 64-bit time_t and convert it to/from a 32-bit time_t to pass to
the kernel. The user will only ever use/see a 64-bit time_t.

>
> The implementation structure generally being used is that the main
> implementation has an interface using 64-bit times (even if it ends up
> using syscalls with 32-bit times) and the one using 32-bit times is a thin

Isn't that what is happening here when __TIMESIZE == 64 ?

> wrapper around it (if time_t is already 64-bit, the second implementation
> does not exist and some macros ensure the first implementation keeps its
> existing name).  Once all functions have been moved to that structure, we
> can set things up so that all those 64-bit functions are exported from
> glibc and add _TIME_BITS support in the headers.

Ah, do you mean that glibc should expose a 64-bit time_t version if
__TIMESIZE == 32? So even __TIMESIZE == 32 systems can call a 64-bit
time_t version (even if the syscall ends up being 32-bit).

Alistair

>
> --
> Joseph S. Myers
> joseph@codesourcery.com