From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from zimbra.cs.ucla.edu (zimbra.cs.ucla.edu [131.179.128.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9A53B1C13 for ; Fri, 3 Mar 2023 05:50:43 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 08B05160084; Thu, 2 Mar 2023 21:50:43 -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 ksyegOz0IZRq; Thu, 2 Mar 2023 21:50:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 0C9AB16008B; Thu, 2 Mar 2023 21:50:42 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.9.2 zimbra.cs.ucla.edu 0C9AB16008B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu; s=78364E5A-2AF3-11ED-87FA-8298ECA2D365; t=1677822642; bh=mEkh6NnzN/U1F+UG59Bsvx9JQjcodis7xuCxOpVU7Ao=; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type: Content-Transfer-Encoding; b=WGDEIdv1Bac8jutIDlmI/uzze63Cj8yFuxoOmjS7h/MD1SwoEEUEztembSL1Zs6r+ V6mgqWLqScYcIGq4EzvbVdmvBzqGQ78wezS2xAGxEEhtcY5ilIFwPMw+7uBnHIp1X+ XgB1t5KSevAoa7gEeoMSvn/kEc9gThxyCTkVSD28= 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 RTlRzKifnJiL; Thu, 2 Mar 2023 21:50:41 -0800 (PST) Received: from [131.179.64.200] (Penguin.CS.UCLA.EDU [131.179.64.200]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 90B92160084; Thu, 2 Mar 2023 21:50:41 -0800 (PST) Message-ID: Date: Thu, 2 Mar 2023 21:50:41 -0800 Precedence: bulk X-Mailing-List: c-std-porting@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Subject: Re: On time64 and Large File Support Content-Language: en-US To: Wookey , =?UTF-8?Q?Daniel_P=2e_Berrang=c3=a9?= Cc: Bruno Haible , "Richard W.M. Jones" , Demi Marie Obenour , Eric Blake , Sam James , Carlos O'Donell via Libc-alpha , autoconf@gnu.org, c-std-porting@lists.linux.dev, Zack Weinberg , David Seifert , Gentoo Toolchain , =?UTF-8?Q?Arsen_Arsenovi=c4=87?= , dueno@redhat.com References: <7253e4c5-0f36-e725-f180-624f8887bf08@cs.ucla.edu> <20230302110244.GK7636@redhat.com> <4158136.ciBtUerH68@nimes> <20230303033045.GO12440@mail.wookware.org> From: Paul Eggert Organization: UCLA Computer Science Department In-Reply-To: <20230303033045.GO12440@mail.wookware.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 3/2/23 19:30, Wookey wrote: > Gnulib automatically changing the ABI for packages that use it is > deeply unhelpful and is going to cause significant breakage and > hassle. This change to Gnulib was reverted in December[1] and that propagated into bleeding-edge GnuTLS last month[2]. So if I understand things correctly the next GnuTLS release will go back to the old way of doing things, which will tempt the 32-bit time_t rearguard to fall back into "Let's not worry about 2038" mode. However this is just one package. We'll likely see similar issues with other packages, independently of whether they use Gnulib, and independently of whether the built packages are not supposed to be used after the year 2038. So this incident is a warning siren for the 32-bit time_t community. It's no time to relax. [1]: https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=7c7c8a519f3892f6f5b30a1c6b22796ab314a45c [2]: https://gitlab.com/gnutls/gnutls/-/commit/9622d7201e1d73d217c18802e1d435ba3404adb3