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 4F505385840F for ; Sat, 12 Nov 2022 19:15:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4F505385840F 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 9023D160079; Sat, 12 Nov 2022 11:15:20 -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 A0q489aNehiv; Sat, 12 Nov 2022 11:15:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 76C20160080; Sat, 12 Nov 2022 11:15:19 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.9.2 zimbra.cs.ucla.edu 76C20160080 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu; s=78364E5A-2AF3-11ED-87FA-8298ECA2D365; t=1668280519; bh=CVzuTEQu/kxa6MfTJ5edRzwClI39SRqbhy6xMRE/hrg=; h=Message-ID:Date:MIME-Version:To:From:Subject:Content-Type: Content-Transfer-Encoding; b=MgCjyNLAWTzBRZgNxLNGlqEt5BnBwpjNrbxtueI0EsUdHZ9sIq35lMAVnrV/22xbP DesLB0hqRC8uNG57MpEwyxKRscas4KRySKOX7qa3N0itNi+CFz2ny2MgydMWsjSqDI WhCfKaAU0YcVr59EhJDx9DdMKo4tQbLmbdnttwpY= 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 N6zad_OrzqbK; Sat, 12 Nov 2022 11:15:18 -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 BDFAE160079; Sat, 12 Nov 2022 11:15:18 -0800 (PST) Message-ID: Date: Sat, 12 Nov 2022 11:15:18 -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: Bruno Haible Cc: 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 References: <6953747.nAD6y4vbrC@nimes> From: Paul Eggert Organization: UCLA Computer Science Department Subject: Re: On time64 and Large File Support In-Reply-To: <6953747.nAD6y4vbrC@nimes> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.4 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 10:50, Bruno Haible wrote: > I'm saying > "tiny" because we are still 15 years away, and new releases of the (not > many) affected packages are likely to come in the next 1-2 years. Not so "tiny", I'm afraid. My department is still running a server with libraries and executables that are over 17 years old. I have asked for it to be decommissioned, but there are backward compatibility concerns. (The OS is still supported by its supplier, and we install security patches, most recently the day before yesterday.) Admittedly my situation differs from embedded environments where _TIME_BITS=64 is likely to make a difference 15 years from now. Unfortunately the situation in embedded environments is often worse. > My assessment is based on the understanding that Zack's proposed change > is essentially [a small change to the code] Yes, that's my understanding too. Unfortunately the Autoconf change would have to be more complicated than that, since documentation and comments would have to change accordingly. And the change to Gnulib code would be considerably more complicated; this inevitably follows from any significant change we make in this area to Autoconf on Savannah. I would rather we spent our limited resources moving forward not backward.