Florian Weimer suggested I write you about a bug in 'stat' and related system
calls, a bug that will become more important as time goes on. The bug is that
when running in a 32-bit application, 'stat' reports incorrect time stamps for
files whose timestamps are so positive (or so negative) that they do not fit
into 32-bit signed integers. POSIX says that such 'stat' calls should fail with
errno == EOVERFLOW, and this is common practice elsewhere. However, the Linux
kernel causes 'stat' to succeed in this situation, discarding the high-order
bits of the time stamp.
This bug is causing gzip 'make test' to fail when built in 32-bit mode and
running atop a 64-bit Linux kernel, as part of gzip's test for out-of-range file
timestamps that are encoded in compressed gzip streams; see:
https://debbugs.gnu.org/bug=25636
I filed a bug report about 'stat' for Fedora here:
https://bugzilla.redhat.com/1419736
and Florian suggested that I raise the issue with you.
Is the intent is that all 32-bit Linux apps will migrate to x32 or some other
model with 64-bit time_t, and that this will happen well before the year 2038 so
the bug is unimportant? Or is the intent that the 32-bit Linux clock will wrap
around after 2038 and go negative? Or is the intent something else? I'd like to
know so that I can fix gzip and other applications and their test cases to match
the intent.
