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 5FB0C3858D1E for ; Fri, 11 Nov 2022 19:56:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 5FB0C3858D1E 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 7982F160048; Fri, 11 Nov 2022 11:56:08 -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 leWLXSlOz6OO; Fri, 11 Nov 2022 11:56:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 9F27A16004F; Fri, 11 Nov 2022 11:56:07 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.9.2 zimbra.cs.ucla.edu 9F27A16004F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu; s=78364E5A-2AF3-11ED-87FA-8298ECA2D365; t=1668196567; bh=5UrD3zenZQH5UEZo0NmAXdYl8T6AHNYDMBLBLvrGDK8=; h=Message-ID:Date:MIME-Version:To:From:Subject:Content-Type: Content-Transfer-Encoding; b=UsKZ92orjPXRcAgKS/OMkMUjKOlKHlNC57ww3nM/l550PUwG6w4flpTdEhe7sIxOP 0BXreUiJPKrQXxYxt7laqWmKUe18wRQialxvdfy5q179aG6iFqeh2qIor3u9fi6l9q k4jlysvpWpVOHzAOvyLiiXUQrtvwCTIdSrpO986U= 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 szTkpE3ZOjZ6; Fri, 11 Nov 2022 11:56:07 -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 5875F160048; Fri, 11 Nov 2022 11:56:07 -0800 (PST) Message-ID: <0a7a9cb2-5335-bb92-ee4c-5698960d767c@cs.ucla.edu> Date: Fri, 11 Nov 2022 11:56:04 -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: Florian Weimer Cc: 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?= , Frederic Berat References: <87wn81q254.fsf@oldenburg.str.redhat.com> <34b6e13f-1905-2632-fde5-47e08a8b14aa@cs.ucla.edu> <87sfippwgd.fsf@oldenburg.str.redhat.com> From: Paul Eggert Organization: UCLA Computer Science Department Subject: Re: On time64 and Large File Support In-Reply-To: <87sfippwgd.fsf@oldenburg.str.redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.6 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-11 03:22, Florian Weimer wrote: > Fortunately, any issues should be quite visibile in > the distribution DWARF data. If we put the time32 switch in place, we > should be able to tell whether it's effective enough in practice. OK, thanks; if problems turn up in that area please let the Autoconf/Gnulib people know what we can do to help address them. > LFS issues have been with us for a long time, and packages and > distributions have workarounds for it (e.g., using off64_t or long long > in public headers). What we have today mostly works. But it's unknown > whether existing AC_SYS_LARGEFILE users require any additional work for > time64 changes. If what we have today mostly works, then it works for blkcnt_t, dev_t, ino_t, off_t and rlim_t, all of whose widths differ on 32-bit x86 glibc depending on whether one compiles with -D_FILE_OFFSET_BITS=64. So there's some precedent for hoping that what we have today will mostly work for time_t and -D_TIME_BITS=64 as well. In hindsight, perhaps it would have been better to have _FILE_OFFSET_BITS=64 also control time_t width, since that would have made for one less configure-time option to worry about. (After all rlim_t can hold 64-bit counts of seconds, so why not time_t?) I suppose it's too late for that now, though.