Paul Eggert <eggert@xxxxxxxxxxx> wrote: > 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. The kernel now offers the statx() system call: http://man7.org/linux/man-pages/man2/statx.2.html But it's not yet supported by glibc. David
