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 3A6CB3858410 for ; Sat, 12 Nov 2022 18:19:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 3A6CB3858410 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 9483C160072; Sat, 12 Nov 2022 10:19:19 -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 LgK79vHyk2N5; Sat, 12 Nov 2022 10:19:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 30A51160079; Sat, 12 Nov 2022 10:19:18 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.9.2 zimbra.cs.ucla.edu 30A51160079 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu; s=78364E5A-2AF3-11ED-87FA-8298ECA2D365; t=1668277158; bh=kpwEYv4uFNTv3P3JrMkPzteZv/k7BgJd8G32YoyB67s=; h=Message-ID:Date:MIME-Version:To:From:Subject:Content-Type: Content-Transfer-Encoding; b=QTi2y4YtQKBz7aPtkuryj/pcljuW+CXx6j+ObOpCDPUygmEm8c7t+C2IeTel4q+dr grnk00EiASivPc4Lp6bhb8oWlACN95BA/rXHcPWT3mQFOZvLcSINQ65m69GIu0rjfH IsyvVnkSOiWbCj+xjUlTGSiiLvIPwQdp29rfiHf8= 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 Rh7K2EWa5ohP; Sat, 12 Nov 2022 10:19:17 -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 B5D1E160072; Sat, 12 Nov 2022 10:19:17 -0800 (PST) Message-ID: <8944cd71-4a18-37c2-1551-0f03408d4bf8@cs.ucla.edu> Date: Sat, 12 Nov 2022 10:19:17 -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: Zack Weinberg , Sam James Cc: Florian Weimer , libc-alpha@sourceware.org, autoconf@gnu.org, c-std-porting@lists.linux.dev, toolchain@gentoo.org, bug-gnulib@gnu.org References: <87wn81q254.fsf@oldenburg.str.redhat.com> 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.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-11 18:20, Zack Weinberg wrote: > I don=E2=80=99t think Paul considered the new behavior of AC_SYS_LARGEF= ILE to be > overriding the glibc maintainers. Rather, I think he was only thinking > about applications, not libraries, and only about source distribution. No, I was thinking about libraries as well. Although there are problems=20 with libraries and time_t, for decades we've had the same problems with=20 AC_SYS_LARGEFILE and off_t, rlim_t, ino_t, etc. Why should time_t be=20 treated differently from the other types? > (It=E2=80=99s unfortunate, IMNSHO, that glibc chose not to provide a ti= me_t > equivalent of _LARGEFILE64_SOURCE, as this means it=E2=80=99s much more > difficult for any shared library other than glibc to offer *both* time_= t > and time64_t binary interfaces.) I can easily understand why glibc didn't take that approach. The LFS API=20 designed in the mid-1990s to support both off_t and off64_t in=20 user-level code was supposed to be a "transitional API", but we're still=20 stuck with it nearly 30 years later, even though almost nobody uses it=20 (and the few who do often don't use it correctly). Even if we weren't=20 dissuaded by the problems of the LFS API, we won't have a luxury of a=20 30-year transition for time_t, as we're only 15 years away from 2038. More generally, the LFS API approach doesn't scale, as the complexity of=20 the implementation would grow exponentially with the number of features=20 involved. Nobody wants to implement or support that sort of thing. This=20 is why glibc put rlimt_t, ino_t, etc. under the off_t umbrella. > I am honestly not sure what to do about this in the long term, but for > the proposed =E2=80=9Cthis weekend, just bugfixes=E2=80=9D Autoconf 2.7= 2, I do think it > makes sense to back out change #2, only =E2=80=94 that is, AC_SYS_YEAR2= 038 will > exist, but AC_SYS_LARGEFILE will *not* imply AC_SYS_YEAR2038.=20 AC_SYS_LARGEFILE doesn't imply AC_SYS_YEAR2038 now, in Autoconf git.=20 Things are a bit more complicated, unfortunately.