> On 12 Nov 2022, at 21:31, Paul Eggert <eggert@xxxxxxxxxxx> wrote: > > On 2022-11-12 12:23, Wookey wrote: >> we can't just have everyone who enabled LFS sometime in the >> last 20 years suddenly being forced into the time_t change (can we?) > > We've done it in the past. > > AC_SYS_LARGEFILE originally was in Gnulib, before it migrated to Autoconf. Originally it affected only off_t; its effect on other types like ino_t came later. Hence people who initially used AC_SYS_LARGEFILE were later "suddenly forced" into an ino_t width change. Similarly for other non-off_t types that AC_SYS_LARGEFILE affects. > > So there's longstanding precedent for AC_SYS_LARGEFILE changing the width of system types that were formerly unaffected. The difference is that time_t is more widely used than ino_t etc., and people are understandably more concerned about time_t changes. > Thanks, that's a helpful bit of history I wasn't aware of there. > > Because of the concerns raised in this thread it's become clear that what's in Autoconf now is too drastic, and I've proposed (though not yet implemented) a change that will cause AC_SYS_LARGEFILE to continue to not affect time_t unless there's an affirmative request like "./configure --enable-year2038". I am waiting for feedback on that from Zack and others, and am hoping for quick turnaround on this because we do need a new Autoconf release. > > Sorry, I missed this until now. That would work well for me too. It's fine for me at least if the same macro just haas additional compatibilities, even if a bit confusing at first. As for further changes (as the original post wasn't exclusive to autoconf), I await comment from other glibc maintainers as I still feel like we're pretty stuck about how to handle this overall. But your suggestion (or zw's patch) puts out or dampens the autoconf fire at least. Thanks for helping come to a compromise. I know this isn't a simple or easy topic at all.
Attachment:
signature.asc
Description: Message signed with OpenPGP
