From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from zimbra.cs.ucla.edu (zimbra.cs.ucla.edu [131.179.128.68]) by sourceware.org (Postfix) with ESMTPS id 3214D3857BB2 for ; Sat, 12 Nov 2022 17:41:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 3214D3857BB2 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=cs.ucla.edu Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=cs.ucla.edu Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 4A184160072; Sat, 12 Nov 2022 09:41:19 -0800 (PST) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id xUzvk6-twqa3; Sat, 12 Nov 2022 09:41:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 77C61160079; Sat, 12 Nov 2022 09:41:15 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.9.2 zimbra.cs.ucla.edu 77C61160079 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu; s=78364E5A-2AF3-11ED-87FA-8298ECA2D365; t=1668274875; bh=sdtO8RRahUQNPuebmcKBSLB3lYOOWSst+SWfi2JGpa0=; h=Message-ID:Date:MIME-Version:To:From:Subject:Content-Type: Content-Transfer-Encoding; b=e5Xt5LaCXwoLsp659d7uPcnF1+siZe8KnldYT8vmDuF+Wv7wLva2j+eplmbKHeMiy JuH1gfAG7yOXEM3as3RC/FZDGpkzVYuvMzfdP0gf++9qCq0OcBizqqi3LGw93UTX8P zgnfnqvgbEqoZwtdZHq3g31sGj8UMfgZLvavuDH8= X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id pR6KGswgIx2c; Sat, 12 Nov 2022 09:41:15 -0800 (PST) Received: from [192.168.1.9] (cpe-172-91-119-151.socal.res.rr.com [172.91.119.151]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 1A2D8160072; Sat, 12 Nov 2022 09:41:15 -0800 (PST) Message-ID: Date: Sat, 12 Nov 2022 09:41:14 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Content-Language: en-US To: Zack Weinberg , Sam James Cc: Florian Weimer , Carlos O'Donell via Libc-alpha , autoconf@gnu.org, c-std-porting@lists.linux.dev, toolchain@gentoo.org, bug-gnulib@gnu.org References: <87wn81q254.fsf@oldenburg.str.redhat.com> <26EF336D-C051-49D6-98A9-EF0707591A6D@gentoo.org> From: Paul Eggert Organization: UCLA Computer Science Department Subject: Re: On time64 and Large File Support In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,JMQ_SPF_NEUTRAL,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,TXREP 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: On 2022-11-12 06:16, Zack Weinberg wrote: > I am going to go ahead and do this if nobody raises a concrete objection > within the next 24 hours. I object to a simple reversion, as this will cause problems downstream with Gnulib-using applications, several of which have already been released assuming the current Autoconf git will go into the next release, and which will stop working if built from Git with an Autoconf 2.72 where the AC_SYS_LARGEFILE changes have been reverted. Current Gnulib assumes that AC_SYS_LARGEFILE will behave in Autoconf 2.72 like what's in Git now. If we change AC_SYS_LARGFILE back, we will need to change Gnulib too, and update downstream apps accordingly. Instead, I suggest a partial reversion, in which AC_SYS_LARGEFILE goes back to its previous meaning by default, but there is a well-documented way to get the current in-Git meaning, a way that Gnulib can recognize and use. For example, you'd get the new meaning if you configure with --enable-year2038, or if configure.ac uses a new macro AC_SYS_LARGER_FILE that supersedes AC_SYS_LARGEFILE. This will also require some Gnulib changes, but they'll be more reliable and stable than whipsaw changes required by reverting then whatever future changes Autoconf makes. This proposal would resolve the backward-compatibility concerns for people who want to delay worrying about year-2038 issues, while also resolving the compatibility concerns of Gnulib. It would also provide a better-documented way for distros that want to switch to 64-bit time_t. Of course this sort of thing cannot be written and tested in an hour. But reverting is not that simple either, and would be a less efficient use of everybody's time.