From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.cs.ucla.edu (mail.cs.ucla.edu [131.179.128.66]) by sourceware.org (Postfix) with ESMTPS id 903813858C56 for ; Fri, 12 Apr 2024 21:24:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 903813858C56 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 ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 903813858C56 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=131.179.128.66 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712957042; cv=none; b=i6bCxIFiM/Ew1CwP5Gr/XyjRXyvXfGtPkW8oewi2vnjwuOY/Zh5tdBuZXxeZ2sXj6d4sMncN+vKuXIJB8cfcIsP50FcaH8w1fm6kgT8NXVsn7JoCcZ3susGC9RcXoYy3Ts/mhfSeUFEawUUCQY7lmzceK1D7vml3R+lZ2rmeR/E= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712957042; c=relaxed/simple; bh=/suOsDEqvaM89+jZQbeLh0l4jeIgSbPNB0K7ZjzsvZo=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=ZPq5vw5bmpPPd8h1Ck8JszAQwQTVFRh2MFpaahc5OC3wrPXZ0XeYrLj1mxcpqDwdM2erYDXhNRtgs3XlJZ7CZhRUw7xsLx4QQX9l0uHmDtGrhc7cRu9X/QRHIyjt5UyG7zIKgxRdBpmS0SxXFh12/Yo4PXTiwFOMorFHdHYyNRk= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id A79F63C011BDC; Fri, 12 Apr 2024 14:23:59 -0700 (PDT) Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavis, port 10032) with ESMTP id 9oGURleaq_eJ; Fri, 12 Apr 2024 14:23:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id 54D8D3C011BDD; Fri, 12 Apr 2024 14:23:59 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.cs.ucla.edu 54D8D3C011BDD DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu; s=9D0B346E-2AEB-11ED-9476-E14B719DCE6C; t=1712957039; bh=W+LZ4cFKE1fzd5A968vhEGu8XDwBFHngoeo8A60PCGY=; h=Message-ID:Date:MIME-Version:To:From; b=W9azt2ZTpfYDcuB6X4+XGYeUatyBkVJvUsOiDRy730XDV+T0NUU1VkGUF5PpchMzC EauGNq/Iuxel83hUXiKVHBresq6XbyRNgTLnaK/JpVL3uMlbTXllz0oLWwcG3dKNnu WvX/Y2O9YJHHRBcwFXyfoS4gAvvOzO0KYWJTxsF6NBUYX+zOi+H3yQa1EM9mbPFyBl AnKt6M/tO59GbOZEtobte8gHohL00E6EP+ZPtOwqKkaRps+sjeA0bY+eBFksA0oWA0 LhaobQOLjwf0M+EmyWtCQ1LfOnJgvSAPeh9nz+GnDv8HbVOLvtt/OusfokLU7bRv4p 7OIm7LX9Ln9NQ== X-Virus-Scanned: amavis at mail.cs.ucla.edu Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id Iu_3a8BlFvRE; Fri, 12 Apr 2024 14:23:59 -0700 (PDT) Received: from [192.168.254.12] (unknown [47.154.17.165]) by mail.cs.ucla.edu (Postfix) with ESMTPSA id 342BD3C011BDC; Fri, 12 Apr 2024 14:23:59 -0700 (PDT) Message-ID: <1600e516-8a88-4ddb-af2f-3e29fd605592@cs.ucla.edu> Date: Fri, 12 Apr 2024 14:23:59 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 2/3] login: structs utmp, utmpx, lastlog _TIME_BITS independence (bug 30701) To: Florian Weimer , libc-alpha@sourceware.org References: Content-Language: en-US From: Paul Eggert Organization: UCLA Computer Science Department In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-9.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,GIT_PATCH_0,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham 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 2024-04-09 23:45, Florian Weimer wrote: > diff --git a/sysdeps/x86/bits/wordsize.h b/sysdeps/x86/bits/wordsize.h > index 70f652bca1..3f40aa76f9 100644 > --- a/sysdeps/x86/bits/wordsize.h > +++ b/sysdeps/x86/bits/wordsize.h > @@ -8,10 +8,9 @@ > #define __WORDSIZE32_PTRDIFF_LONG 0 > #endif > > +#define __WORDSIZE_TIME64_COMPAT32 1 > + > #ifdef __x86_64__ > -# define __WORDSIZE_TIME64_COMPAT32 1 > /* Both x86-64 and x32 use the 64-bit system call interface. */ > # define __SYSCALL_WORDSIZE 64 > -#else > -# define __WORDSIZE_TIME64_COMPAT32 0 > #endif I'm still having a few qualms about this part of the patch, and similarly for ARM. To continue from an earlier round: >> > On 4/3/24 11:39, Florian Weimer wrote: >>> >> For consistency, >>> >> if there is a 64-bit architecture that is coinstallable, define >>> >> __WORDSIZE_TIME64_COMPAT32 to 1 on the 32-bit architectyre as well. >> > >> > Could you explain the advantage of consistency here? User code almost >> > invariably assignes ut_tv.tv_sec to time_t (this is true of every >> > instance I found of ut_tv in Gnulib source code, for example). So >> > changing this field's type on platforms where time_t is 32 bits will >> > likely be ineffective in practice, and might cause more problems than >> > it cures. > > Few applications with a 32-bit time_t will work once there is a value in > this field with the MSB set. So the relevant case is applications that > were built with -D_TIME_BITS=64, and there the consistent behavior with > the 64-bit architecture helps. It appears that I was not clear, as I was worried about applications built on 32-bit ARM or x86 without -D_TIME_BITS=64, so please let me try again. For obsolescent 32-bit time_t apps that deal with 32-bit on-disk timestamps I see two forms of "consistent behavior": A. These obsolescent apps should behave consistently with how they've behaved for decades. B. These obsolescent apps should behave consistently with how 64-bit time_t apps work on the same platform for timestamps after 2038. Surely consistency (A) is more important than consistency (B). As you mentioned, there are countless other reasons these obsolescent apps won't work after 2038, so consistency (B) has no value. In contrast, consistency (A) - which is essentially "don't fiddle with obsolescent apps" - has the value of stability. In other words, because it's better to not disturb obsolescent apps, we should leave ut_tv.tv_sec alone when apps are built with 32-bit time_t, even on platforms where there is a 64-bit arch that is coinstallable.