On Thu, Jun 02, 2022 at 05:46:05PM +0200, Petr Pisar wrote:
$ gcc -m32 -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 main.c
$ ./a.out
sizeof(time_t)=8
I recommend you to file a bug against tar in Fedora's Bugzilla. However, this
proposed solution would require rebuilding in the same way all libraries which
tar uses and which pass time_t and similar types in their interface. That
would probably break other packages.
Now that the kernel and glibc have this feature, would it make sense
to change the global CFLAGS to build everything with 64-bit time_t on
all currently supported 32-bit archs? If not now, how close to the
32-bit overflow in 2038?
It's not just about keeping current time and file timestamps. There
are applications/libraries that calculate future dates and overflows
can lead to serious issues.
Switching to 64-bit time_t may require some patching, e.g. when the
code assumes sizeof(long) == sizeof(time_t).
--
Miroslav Lichvar