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 <[email protected]> > Link: > https://lore.kernel.org/lkml/[email protected]/ > Signed-off-by: Thomas Weißschuh <[email protected]> > --- > 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
