On Mon, Dec 1, 2025, at 11:35, Willy Tarreau wrote:
On Mon, Dec 01, 2025 at 08:45:00AM +0100, Arnd Bergmann wrote:
On Sun, Nov 30, 2025, at 11:58, Willy Tarreau wrote:
#if __TIMESIZE == 64 && __WORDSIZE == 32 # define __TIME_T_TYPE __SQUAD_TYPE # define __SUSECONDS_T_TYPE __SQUAD_TYPE #else # define __TIME_T_TYPE __SLONGWORD_TYPE # define __SUSECONDS_T_TYPE __SLONGWORD_TYPE #endif
so this one is explicitly the same width as tv_sec, which has all the issues you listed, but avoids the need for padding.
Ah we seem to just have checked different versions then, as in mine there was still some extra padding left depending on the endianness :-)
The padding is definitely there in timespec around tv_nsec, just not in timeval.
Oddly, the version I quoted is from my arm64 /usr/include/ installation and looks different from what I see in the glibc history, though that also uses a 64-bit tv_usec:
bits/typesizes.h:#define __SUSECONDS64_T_TYPE __SQUAD_TYPE posix/bits/types.h:__STD_TYPE __SUSECONDS64_T_TYPE __suseconds64_t; struct timeval { #ifdef __USE_TIME64_REDIRECTS __time64_t tv_sec; /* Seconds. */ __suseconds64_t tv_usec; /* Microseconds. */ #else __time_t tv_sec; /* Seconds. */ __suseconds_t tv_usec; /* Microseconds. */ #endif };
C23 has updated the definition and does allow int64_t tv_nsec.
So it purposely breaks existing apps or does it apply only to those compiled with -mstd=c23 ?
Neither, it's just that nolibc with a 64-bit tv_nsec would be compliant with c23, just not earlier versions.
I expect glibc to stick with 32-bit timespec and padding, which is still compliant with the new definition of
| The type of tv_nsec is an implementation-defined signed integer type | that can represent integers in [0, 999999999].
I think it makes sense for nolibc to just follow the kernel's definition here.
Given the very narrow range of existing code that can be impacted, I'm fine, but in general I try to remain extremely cautious about portability: as a general rule, ifdefs needed to address possible incompatibilities, if any, should rather be in the libc code itself and not in the user application. I just ran a quick check and don't have code using &tv_usec nor &tv_nsec so here the risk remains quite low.
Ok
ARnd