[PATCH v2 2/5] y2038: Introduce struct __timeval64 - new internal glibc type

[Alistair Francis]

On Mon, Jan 27, 2020 at 12:53 AM Lukasz Majewski <lukma@denx.de> wrote:
>
> This type is a glibc's "internal" type similar to struct timeval but
> whose tv_sec field is a __time64_t rather than a time_t, which makes it
> Y2038-proof. This struct is NOT supposed to be passed to the kernel -
> instead it shall be converted to struct __timespec64 and clock_[sg]ettime
> syscalls shall be used (which are now Y2038 safe).
>
> Build tests:
> ./src/scripts/build-many-glibcs.py glibcs
>
> ---
> Changes for v2:
> - Replace __suseconds_t with __suseconds64_t
> ---
>  include/time.h | 14 ++++++++++++++
>  1 file changed, 14 insertions(+)
>
> diff --git a/include/time.h b/include/time.h
> index 047f431a1a..99492a1577 100644
> --- a/include/time.h
> +++ b/include/time.h
> @@ -93,6 +93,20 @@ struct __itimerspec64
>  };
>  #endif
>
> +#if __TIMESIZE == 64
> +# define __timeval64 timeval
> +#else
> +/* The glibc Y2038-proof struct __timeval64 structure for a time value.
> +   This structure is NOT supposed to be passed to the Linux kernel.
> +   Instead, it shall be converted to struct __timespec64 and time shall
> +   be [sg]et via clock_[sg]ettime (which are now Y2038 safe).  */
> +struct __timeval64
> +{
> +  __time64_t tv_sec;         /* Seconds */
> +  __suseconds64_t tv_usec;       /* Microseconds */
> +};
> +#endif

Can this be moved to time/bits/types/struct_timeval.h?

The reason is that we need it in include/bits/types/struct_rusage.h
and including time.h results in exposed symbols (from memory I see
glibc test failures when trying to do this).

The other problem is that we need __timeval64 in time/sys/time.h for
__getitimer64() and __setitimer64() and include/time.h isn't included
in there.

Alistair

> +
>  #if __TIMESIZE == 64
>  # define __ctime64 ctime
>  #else
> --
> 2.20.1
>