Re: [PATCH v2 09/13] tools/nolibc: always use 64-bit time types

[Willy Tarreau <w@1wt.eu>]

Hi Thomas,

On Sat, Nov 22, 2025 at 05:59:15PM +0100, Thomas Weißschuh wrote:
> 32-bit time types will stop working in 2038.
> 
> Switch to 64-bit time types everywhere.
> 
> Suggested-by: Arnd Bergmann <arnd@arndb.de>
> Link: https://lore.kernel.org/lkml/cec27d94-c99d-4c57-9a12-275ea663dda8@app.fastmail.com/
> Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
> ---
>  tools/include/nolibc/std.h   | 2 +-
>  tools/include/nolibc/types.h | 9 +++++----
>  2 files changed, 6 insertions(+), 5 deletions(-)
> 
> diff --git a/tools/include/nolibc/std.h b/tools/include/nolibc/std.h
> index 392f4dd94158..b9a116123902 100644
> --- a/tools/include/nolibc/std.h
> +++ b/tools/include/nolibc/std.h
> @@ -29,6 +29,6 @@ typedef unsigned long       nlink_t;
>  typedef  int64_t              off_t;
>  typedef   signed long     blksize_t;
>  typedef   signed long      blkcnt_t;
> -typedef __kernel_time_t      time_t;
> +typedef __kernel_time64_t    time_t;
>  
>  #endif /* _NOLIBC_STD_H */
> diff --git a/tools/include/nolibc/types.h b/tools/include/nolibc/types.h
> index 5d180ffabcb6..8f3cb18df7f1 100644
> --- a/tools/include/nolibc/types.h
> +++ b/tools/include/nolibc/types.h
> @@ -17,14 +17,15 @@
>  #include <linux/wait.h>
>  
>  struct timespec {
> -	__kernel_old_time_t	tv_sec;
> -	long			tv_nsec;
> +	time_t	tv_sec;
> +	int64_t	tv_nsec;
>  };
>  #define _STRUCT_TIMESPEC
>  
> +/* Never use with system calls */
>  struct timeval {
> -	__kernel_old_time_t	tv_sec;
> -	__kernel_suseconds_t	tv_usec;
> +	time_t	tv_sec;
> +	int64_t	tv_usec;
>  };

It seems to me that glibc continues to make the effort of using a long
for tv_usec and tv_nsec. At least I'm seeing how that can make a
difference for application code given that these fields are constantly
multiplied or divided, forcing them to 64-bit when we know they'll never
be larger than 1 billion is extra burden for the application. Another
reason might be that the definition really changed from long to suseconds_t
in timeval a while ago, it's possible that it's used as a long in various
APIs (or even just printf formats).

IMHO it would be cleaner to keep it as a long here, or do you have a
particular reason for wanting int64_t (which BTW already forced a cast
in sys_gettimeofday()) ?

Thanks,
Willy