From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.gentoo.org (woodpecker.gentoo.org [140.211.166.183]) by sourceware.org (Postfix) with ESMTP id 525A93858409 for ; Fri, 11 Nov 2022 09:19:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 525A93858409 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gentoo.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gentoo.org Content-Type: multipart/signed; boundary="Apple-Mail=_14E79669-8CE1-44CA-94F3-C7A44FCDDF0A"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.200.110.1.12\)) Subject: Re: On time64 and Large File Support From: Sam James In-Reply-To: Date: Fri, 11 Nov 2022 09:19:31 +0000 Cc: 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?= Message-Id: References: To: Paul Eggert X-Mailer: Apple Mail (2.3731.200.110.1.12) X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_PASS,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: --Apple-Mail=_14E79669-8CE1-44CA-94F3-C7A44FCDDF0A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 11 Nov 2022, at 09:16, Paul Eggert wrote: >=20 > On 2022-11-11 00:38, Sam James wrote: >> All that to say, I don't propose making these options unconditional, >> because I think the boat has sailed as of glibc-2.34 [4], and I think >> it's fair that autoconf keep the behaviour as described in git master >> right now given the situation with glibc, but I don't think it's >> a wise path for most distributions to follow. > As a practical matter, I expect that each distro will have to do a = big-bang move, assuming the distro want to support traditional 32-bit = platforms at all. It makes little sense to try to have some programs and = libraries with 32-bit time_t, while others have 64-bit time_t. Just = switch to 64-bit time_t everywhere. >=20 > This is not something distros can put off for long. We're only 15 = years from when 32-bit time_t stops working. If distros plan to to = support traditional 32-bit platforms, they really need to do the = big-bang move soon. They can do it by predefining _TIME_BITS=3D64 and = _FILE_OFFSET_BITS=3D64, or by using the new Autoconf macros, or = whatever. >=20 > One possible way forward would be for glibc to change its defaults for = _FILE_OFFSET_BITS and _TIME_BITS to be 64, in the next major release. = This would make it easier to do a big-bang switch, which is what people = need to do anyway. The backward-compatibility argument for defaulting = these to 32 is making less and less sense as time goes on. +1. I completely agree and I've reached the same conclusion. My suggestion = for configure args was to be a bit more gentle and avoid controversy, but really, your = suggestion would work and would force distros to handle it at the same time, which is best for users. (And I really did try to make piecemeal work, but I've decided it = can't.) I think we're at risk of distros either putting this off or equivocating = which just harms our users. I should've spoken up at the time of 2.34. FWIW, musl did this and it really was for the best: = https://musl.libc.org/time64.html. --Apple-Mail=_14E79669-8CE1-44CA-94F3-C7A44FCDDF0A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iNUEARYKAH0WIQQlpruI3Zt2TGtVQcJzhAn1IN+RkAUCY24To18UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0MjVB NkJCODhERDlCNzY0QzZCNTU0MUMyNzM4NDA5RjUyMERGOTE5MAAKCRBzhAn1IN+R kBHmAQCN4cEP02Rs+il7OQdpM2IFmR+qbh3XT6YMg13rwz1lGQD/UWUdgkGixDT5 Iy9aZOH8lc7SmY3tZsygzU+yxS881gs= =KXMO -----END PGP SIGNATURE----- --Apple-Mail=_14E79669-8CE1-44CA-94F3-C7A44FCDDF0A--