From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from haven.eyrie.org (haven.eyrie.org [IPv6:2001:470:30:84:e276:63ff:fe62:3539]) by sourceware.org (Postfix) with ESMTPS id 0C5753858407 for ; Sat, 12 Nov 2022 20:54:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0C5753858407 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=eyrie.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=eyrie.org Received: from lothlorien.eyrie.org (96-90-234-101-static.hfc.comcastbusiness.net [96.90.234.101]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by haven.eyrie.org (Postfix) with ESMTPS id 41D0011806A; Sat, 12 Nov 2022 12:54:44 -0800 (PST) Received: by lothlorien.eyrie.org (Postfix, from userid 1000) id 23CA9B437D2; Sat, 12 Nov 2022 12:54:43 -0800 (PST) From: Russ Allbery To: Wookey Cc: Paul Eggert , Bruno Haible , Zack Weinberg , Sam James , Florian Weimer , Carlos O'Donell via Libc-alpha , autoconf@gnu.org, c-std-porting@lists.linux.dev, toolchain@gentoo.org, bug-gnulib@gnu.org, Arnd Bergmann Subject: Re: On time64 and Large File Support In-Reply-To: <20221112202321.GO27919@mail.wookware.org> (wookey@wookware.org's message of "Sat, 12 Nov 2022 20:23:21 +0000") Organization: The Eyrie References: <6953747.nAD6y4vbrC@nimes> <20221112202321.GO27919@mail.wookware.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) Date: Sat, 12 Nov 2022 12:54:42 -0800 Message-ID: <87bkpbx59p.fsf@hope.eyrie.org> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Wookey writes: > Now, I'm not yet sure if just having autoconf 2.72 will actually break > things. AIUI, these changes only apply where LFS > (-D_FILE_OFFSET_BITS=64) is turned on, so in Debian at least, where that > is not the default on 32bit arches, maybe this is OK. But probably quite > a lot of packages already enable LFS so they are suddenly going to get a > new ABI if they expose timet anywhere? > https://codesearch.debian.net/search?q=AC_SYS_LARGEFILE&perpkg=1 shows > 163 pages of hits, and a quick peruse suggsts that AC_SYS_LARGEFILE is > used by a lot of packages (as you might expect - this transition has > been going on for many years). And just having that macro in > configure.(in|ac) will turn 64-bit timet on if you autoreconf with > 2.72. Right? If indeed pre-existing use of AC_SYS_LARGEFILES would suddenly enable 64-bit time_t on autoreconf, I can name two packages just off the top of my head that this change to Autoconf will immediately break if their Debian packages are rebuilt with a newer version of Autoconf, creating severe bugs. libremctl will have its ABI changed without any coordination or versioning (which I will be doing, moving forward, but have not started tackling yet in part because I was waiting to see what the plan would be and whether there will be some coordinated change to SONAMEs, a new architecture, or what). And INN, which admittedly is a disaster about things like this for lots of historical reasons, will have its *on-disk file format* changed without notice in a way that will cause serious failure and possibly data corruption on upgrades. This is just wildly backward-incompatible and seems like an awful idea. If we're going to throw a big switch and rebuild everything, it needs to be done at a distro-wide level. I believe the only safe thing for Autoconf to do is to provide an opt-in facility, similar to what was done for AC_SYS_LARGEFILE, and then leave deciding whether to opt in to higher-level machinery. > However my limited understanding as of right now says that autoconf 2.72 > tying 64bit time_t to use of AC_SYS_LARGEFILE means that 2.72 can't be > used in debian yet. So I currently favour not tying them together in > this release. That's also my understanding from the thread so far, although I'm not sure that I'm following all of the subtleties. > People have been using AC_SYS_LARGEFILE without 64bit time_t for many > years now so it's not yet clear to me why that cannot continue. And these are conceptually not at all the same thing. I saw Paul's explanation for why he views them as fundamentally the same because of their effect on system calls like stat, but I certainly don't think of them that way and I am quite dubious many other people will either. The set of things that I have to check to ensure that time_t is handled correctly is totally different than the set of things I thought about when enabling AC_SYS_LARGEFILE many years in the past. I recognize that there will be overlap once file timestamps are past 2038 and that will happen sooner than anyone plans for, but it's still true that this has *not* happened right now and this therefore is not currently creating many bugs, whereas this switch in this way will create many, very serious bugs immediately. -- Russ Allbery (eagle@eyrie.org)