Time types could overflow on 32-bit systems

[robotman2412]

While writing the BadgerOS sysdeps (which I will eventually seek to upstream), I noticed that certain types, most notably including time_t are defined as long, which would make them 32-bit on 32-bit systems. For time, however, this has the 2038 bug as struct timespec would contain a signed 32-bit integer for tv_sec. I would like to request an option to make these __mlibc_int64 instead so users can enable a 2038-safe type on 32-bit platforms as well.

[robotman2412]

I should add that the current situation does not allow me to create the ABI I want for 32-bit BadgerOS in the future; I could write a pull request for you that would fix this.

[avdgrinten]

True, it's a known limitation that we do not support the 64-bit time_t ABI on Linux. PRs would be welcome in this area (but we should try to be ABI compatible with glibc here etc).

[avdgrinten]

Maybe the most reasonable option is to simply only support 64-bit time_t (however, this requires changes in the Linux sysdeps).

[robotman2412]

This is why I suggested making this an additional option; existing ABI could be retained if you simply don't opt in to 64-bit time_t.

[avdgrinten]

This only affects 32-bit x86 and m68k though and these systems do not have a lot of users so breaking ABI may not be that problematic.

[robotman2412]

Does mlibc not support 32-bit RISC-V or does it use a different source of time_t there? 32-bit RISC-V would then be something I'm looking to add future support for.

[marv7000]

It does not support 32-bit RISC-V.