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 05DFD3858CDB for ; Thu, 2 Mar 2023 10:28:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 05DFD3858CDB 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 C3030160066; Thu, 2 Mar 2023 02:28:31 -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 n3Y4eknOYMEt; Thu, 2 Mar 2023 02:28:31 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id F053F16006A; Thu, 2 Mar 2023 02:28:30 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.9.2 zimbra.cs.ucla.edu F053F16006A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu; s=78364E5A-2AF3-11ED-87FA-8298ECA2D365; t=1677752911; bh=HkisWSt22LaHwiylVC7htsZWsN19XrvHZvQOVsKqYrc=; h=Message-ID:Date:MIME-Version:To:From:Subject:Content-Type: Content-Transfer-Encoding; b=KYjMXi/xMi3RoXrAJ4zY1dDbTOOvu1WAalx2jNCjB72hmm+uGLPupqK5vp4uWmtsj OcjuzMEl9bK/E+obXvT0vKfmDbuWQwOcFylXkMN0PfYjry2wA5E9Pr0VbYYZN22Wr4 efYeANHMZWuMXDAQCTxsxMvLCzVEZFYAjhuw2NjU= 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 SVbGqnd9Gq7r; Thu, 2 Mar 2023 02:28:30 -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 EC2BF160066; Thu, 2 Mar 2023 02:28:29 -0800 (PST) Message-ID: <7253e4c5-0f36-e725-f180-624f8887bf08@cs.ucla.edu> Date: Thu, 2 Mar 2023 02:28:28 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1 To: =?UTF-8?Q?Daniel_P=2e_Berrang=c3=a9?= , Demi Marie Obenour Cc: 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?= , rjones@redhat.com References: <20230301223859.chl5o3bedqckf3tx@redhat.com> <086d6fcd-3738-cc7f-db72-6a8d19d33e30@gmail.com> Content-Language: en-US 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: quoted-printable X-Spam-Status: No, score=-2.2 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 2023-03-02 01:04, Daniel P. Berrang=C3=A9 wrote: > IMHO if distros really want to deal with this, they need to be able to > force _TIME_BITS=3D64 globally / unconditionally, and do a mass rebuild= . As things stand this is probably the best way to go. Although some pain=20 is inevitable, this approach appears to be the least painful. Mainstream developers long ago migrated to 64-bit time_t, and fewer and=20 fewer of them have the time to worry about the shrinking subset of the=20 embedded system world where legacy 32-bit time_t is still OK (at least=20 for the next several months). It's incumbent on system builders who=20 still cater to legacy 32-bit time_t (for now) to figure out how to=20 wrangle their systems into the 64-bit time_t world; they can't really=20 expect Glibc, Gnulib, Autoconf, GnuTLS, etc. to make the job much easier=20 than it already is. > So while there is a chance of inconsistent usage [with off_t], and thus > ABI incompatibility, in practice this is a non-issue since everything > of consequence has long ago opted in to _FILE_OFFSET_BITS=3D64. Fifteen years from now we'll be saying the same thing about _TIME_BITS.=20 There will be some pain in the meantime, just as there was with the=20 _FILE_OFFSET_BITS transition, something I lived through and was not too=20 happy about either.