On 2022-11-10 19:33, Zack Weinberg wrote:

> It would be relatively easy for me to take a couple hours this weekend and put out a 2.72 release with everything that's already in trunk and nothing else.  Anyone have reasons I _shouldn't_ do that?

I don't have anything other than some doc updates, which I just now 
installed (see attached).

>> Note that in autoconf git, we've also got
>> https://git.savannah.gnu.org/cgit/autoconf.git/commit/?id=f6657256a37da44c987c04bf9cd75575dfca3b60
>> which is going to affect time_t efforts too
> 
> I have not been following the y2038 work closely.  Is it going to affect things in a good way or a bad way??

Both.

This matters only on 32-bit glibc platforms running atop Linux (and 
maybe Hurd; I haven't checked). On these platforms, time_t defaults to 
32 bits which means programs stop working in the year 2038. But you can 
change time_t to be 64-bits if you compile with -D_FILE_OFFSET_BITS=64 
-D_TIME_BITS=64. On other platforms, you don't need to worry about this 
stuff.

The good news is that if an app uses AC_SYS_LARGEFILE (which most sane 
apps do), or uses the new macro AC_YEAR2038, it will keep working after 
the year 2038 on these platforms.

The bad news is that if a library uses AC_SYS_LARGEFILE and/or 
AC_YEAR2038, and the library code is built without using configure's 
--disable-largefile option and is linked with a program that doesn't use 
AC_SYS_LARGEFILE or AC_YEAR2038 or equivalent, and if the library's ABI 
depends on time_t width, the program might not work.

This is the same issue that AC_SYS_LARGEFILE has had with 32-bit off_t 
for years (as well as for a few more obscure times like ino_t); what's 
new is that the problem now occurs with time_t too.