[PATCH] Rename STAT_HAS_TIME32 to KERNEL_STAT64_HAS_TIME32
Arnd Bergmann
arnd@arndb.de
Tue Nov 8 11:21:31 GMT 2022
On Mon, Nov 7, 2022, at 19:45, Adhemerval Zanella Netto wrote:
> On 07/11/22 15:24, Arnd Bergmann wrote:
>> What is the glibc behavior for i386 with 64-bit time_t on a
>> kernel without statx? Does that also intepret a time value
>> of -1u as a 2106 timestamp, or does it convert that into a
>> 1969 timestamp like the other (not mips/pa-risc) 64-bit
>> architectures do?
>
> The time_t for glibc is always signed and for legacy 32-bit ABIs
> it issues fstatat64 and assumes that kernel will handle potential
> overflow by returning a proper error (if syscall succeeds then the
> file times are within the signed 32 bit time_t range).
>
> My understanding is mips is the only outlier here with unsigned
> kernel stat times, which on glibc is handled with a special function
> that just that interprets the values as 2106 timestamp
> (__cp_kstat_stat64_t64).
Ok, got it. In this case I guess we should probably follow the
same behavior in the kernel when we add the truncation and
use the 1902..2038 range for all 32-bit targets but use the
1970..2106 range for mips64. Not sure what to do about
mips32 compat mode though. At the moment, the o32/n32 stat64
is shared with the n64 stat ("newstat") variant, but if n64
actually wants a different behavior, we may need to add custom
handlers for that.
Arnd
More information about the Libc-alpha
mailing list