long vs long long in struct timex

[Florian Weimer]

* Hal Murray via Libc-help:

> Who decided that those slots should be long long rather than long, and
> why?

It's the struct layout that the clock_adjtime64 system call expects, so
it's more of a Linux question.  This seems to be a related kernel
commit:

commit 3876ced476c8ec17265d1739467e726ada88b660
Author: Deepa Dinamani <deepa.kernel@gmail.com>
Date:   Mon Jul 2 22:44:22 2018 -0700

    timex: change syscalls to use struct __kernel_timex
    
    struct timex is not y2038 safe.
    Switch all the syscall apis to use y2038 safe __kernel_timex.
    
    Note that sys_adjtimex() does not have a y2038 safe solution.  C libraries
    can implement it by calling clock_adjtime(CLOCK_REALTIME, ...).
    
    Signed-off-by: Deepa Dinamani <deepa.kernel@gmail.com>
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>

But you'll need to dig further to find out why __kernel_timex uses
64-bit fields in places where you consider 32-bit fields sufficient.

We are just following the kernel interface here.  If we had chosen
different types, we would have to rewrite structs before we can pass
them to the kernel.

> What is __USE_TIME64_REDIRECTS?  Is that relevant to this discussion?

It's used on older 32-bit targets to indicate that time_t uses 64 bits.

> Why is there a linux/timex.h if it's never used?  Or when/why is it
> used?

Those are header files supplied by Linux for use in userspace.  We only
use a subset of them in glibc.  Looking at <linux/timex.h>, it's not
usable because it does not define the expected types with the right
struct tags.

Thanks,
Florian