On 2024/5/15 下午10:25, Arnd Bergmann wrote:
On Wed, May 15, 2024, at 09:30, maobibo wrote:
On 2024/5/11 下午8:17, Arnd Bergmann wrote:
On Sat, May 11, 2024, at 12:01, Huacai Chen wrote:
Importantly, we can't just add fstatat64() on riscv32 because there is no time64 version for it other than statx(), and I don't want the architectures to diverge more than necessary.
yes, I agree. Normally there is newfstatat() on 64-bit architectures but fstatat64() on 32-bit ones.
I do not understand why fstatat64() can be added for riscv32 still. 32bit timestamp seems works well for the present, it is valid until (0x1UL << 32) / 365 / 24 / 3600 + 1970 == 2106 year. Year 2106 should be enough for 32bit system.
There is a very small number of interfaces for which we ended up not using a 64-bit time_t replacement, but those are only for relative times, not epoch based offsets. The main problems here are:
time_t is defined to be a signed value in posix, and we need to handle file timestamps before 1970 in stat(), so changing this one to be unsigned is not an option.
A lot of products have already shipped that will have to be supported past 2038 on existing 32-bit hardware. We cannot regress on architectures that have already been fixed to support this.
file timestamps can also be set into the future, so applications relying on this are broken before 2038.
I see. And thanks for detailed explanation.
Regards Bibo Mao
Arnd