From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 1D02B3858D32 for ; Mon, 15 Apr 2024 09:29:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 1D02B3858D32 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 1D02B3858D32 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1713173347; cv=none; b=WNEJ8mLKnzyF09GrEByHz+ahX+CLQlVORrMJhp0N/NrXLX73eH66f7TmykGy2M//pRzRA/TL15mLDVlxKtwWt//jk1hzavbXwxp2HMmJ9zSomP/DMsqLaNvg1lW4or6QNLiXFt3HnB8sHjUx+uqeRV/yS/LEj7riy/A4elqI4Pw= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1713173347; c=relaxed/simple; bh=1/fccrLoI4JW+KKWuWOg9ySP8+0ixRT/SUwXPNaF64I=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=qxqJgUjUUOZcsgzhEXhOXqg9qBBxGrVlfBL+AFIIA6uc6JqgQ8sPNNhoTgiEnYS61QqxxMZ2NkZ17OmlmrZWSxZ/V3zgy8r9A0NSnpSawjpaohFkBVNLFGHtdv8P6kXn5sIkvN/ryLzZufj9RxZ0IETbOPcHbEKhwcMLTt1bJQE= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1713173345; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=SDWSz8du6TxGRMgCXzxr1pqA6nsxGJf+qna+RjQ1DF8=; b=gZIEHJbnY/WElZUBQjfNk6TilDziCMJOpSy7DWSv90QXbcEORqV5Eea9NtFh8W0WhR1H5r Wk/dv/dDnAji0YSljGL8cSJLmm+coUWUcyvOogkhYbH3ua9KWi+2BlLm6YGre4Z0GpNX34 lhCifnIQO+vvx+ryYsgQBZLPxaCq3eo= Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-586-iH3hpG2dOKmR0NRBoMoNqQ-1; Mon, 15 Apr 2024 05:29:02 -0400 X-MC-Unique: iH3hpG2dOKmR0NRBoMoNqQ-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.rdu2.redhat.com [10.11.54.7]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 2DAD83806735; Mon, 15 Apr 2024 09:29:02 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.193.229]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 7FF7D1C0666D; Mon, 15 Apr 2024 09:29:01 +0000 (UTC) From: Florian Weimer To: Paul Eggert Cc: libc-alpha@sourceware.org Subject: Re: [PATCH v3 2/3] login: structs utmp, utmpx, lastlog _TIME_BITS independence (bug 30701) In-Reply-To: <1600e516-8a88-4ddb-af2f-3e29fd605592@cs.ucla.edu> (Paul Eggert's message of "Fri, 12 Apr 2024 14:23:59 -0700") References: <1600e516-8a88-4ddb-af2f-3e29fd605592@cs.ucla.edu> Date: Mon, 15 Apr 2024 11:28:55 +0200 Message-ID: <87h6g3nfe0.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.7 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-11.9 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,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: * Paul Eggert: > 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). Thank you, I think I better understood your position now. The patch here is a source-only change. Applications which are not recompiled are unaffected by it. So it does not necessarily contradict (A), depending on how you read it. With the present patch, the type follows this rule: If the field size is 64 bits, its type is time_t, otherwise the field type is uint32_t. Your proposal would lead to a rule like this: If the field size is 64 bits, it is time_t. If the field size is 32 bits and time_t is 64 bits (in this translation unit), the field type is uint32_t. Otherwise the field size is 32 bits and its type is int32_t. >From an application perspective, I don't think much changes. Applications should process the field value as int64_t anyway, operating on a copy. (No conditional compilation should be needed.) So no extra conditional code should be needed compared to the simpler rule I implemented. The glibc header change would be a bit more involved because we currently do not define __USE_TIME_BITS64 for Hurd, as far as I can see (and the installed is probably garbled, so is broken?). The tests probably would rely on a new macro in . I can implement it that way, but I'm not sure if it's worth the complexity. This would only benefit obsolescent applications that are recompiled. Thanks, Florian