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 B1A6A3847725 for ; Wed, 3 Apr 2024 21:20:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B1A6A3847725 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 B1A6A3847725 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=1712179210; cv=none; b=ASfrfkIhHwz/BXyrh+YwLdP8TDDmCC2Hhz6uSs3vhMRzLd3jBx1YAx5v8uQ8nEuBJg7erFbIuG2DwrnL2MRlIRoCegz2/pPpSe2oV2uZ45dIHRe6p14/UdZ/pUvdvKdqQsr/HYMcxZDU3hCWxXE7erH2KEC6iESayhyBImJHAHU= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712179210; c=relaxed/simple; bh=rDpYguRmjlciEzDNiT+Sd0Y/FRXlKD+Vlmh3Ejnzwcc=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=xLuugpm2VYIRVEWZOulZ/+YRuuZpLo0Hj/8fLrDHKMylpfg2bfXp+OFjLxnM0RcHP8O1td7Qu1PP99NyPlguc4BouF+6fVtrQ77UCZkpX9lYlAybQqW8A8ZqSMwCYrghiF61lIErYqgx6V+d/2uIwTOevdGN0B1Th/YIxlnMynk= 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 0A37A3C011BD4; Wed, 3 Apr 2024 14:20:08 -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 M2vWy9iAMFkO; Wed, 3 Apr 2024 14:20:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id AB2C13C011BD7; Wed, 3 Apr 2024 14:20:07 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.cs.ucla.edu AB2C13C011BD7 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu; s=9D0B346E-2AEB-11ED-9476-E14B719DCE6C; t=1712179207; bh=PlIv0EMJL/Tfit8Bw23jOJI3ReiUjCKJSnsQuVi/JLY=; h=Message-ID:Date:MIME-Version:To:From; b=CYtJ1+GAw3pi1eZnFfl8Cl97gddPuoC8eQ/5Ksx5MvB5BouN9zXiY21m0HegB8vnr m2BLJMZR2vxYhu+P2XZ7Dnzg6uAX1LO0vI0WZWp6ytEZtHlolLcH2FBSWzR1w1zjC8 Y3NGydeDqAzHiybgAY8YZDlXs0wmOlo7anaxwpxH2jFZpWMnZ9AjD6pACb+YWL79V4 +S0F38hWZJrlPPICEE4gkd9f/P4xjSgKZvyHE3MkEVFLIFimReYqMCQWpQKeXzNQ9d 7/dVT6SkK0O9P9j86MC7HXqQbgBOZZpl1v4ptNaC/sMo92N/yePDr01fF0+9DmEYdQ 3VvmEnSQ7Su1A== 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 U3w0rkb0X-dx; Wed, 3 Apr 2024 14:20:07 -0700 (PDT) Received: from [131.179.64.200] (Penguin.CS.UCLA.EDU [131.179.64.200]) by mail.cs.ucla.edu (Postfix) with ESMTPSA id 92DC83C011BD4; Wed, 3 Apr 2024 14:20:07 -0700 (PDT) Message-ID: <6289d40a-7989-4869-8f47-553263e4df7a@cs.ucla.edu> Date: Wed, 3 Apr 2024 14:20:07 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] login: Use unsigned 32-bit types for seconds-since-epoch To: Florian Weimer References: <87sf02guiz.fsf@oldenburg.str.redhat.com> Content-Language: en-US Cc: libc-alpha@sourceware.org From: Paul Eggert Organization: UCLA Computer Science Department In-Reply-To: <87sf02guiz.fsf@oldenburg.str.redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,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 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. Since the _TIME_BITS==32 world is going away anyway by 2038, it might be better to leave the field types unchanged in that world, to lessen compatibility glitches before that world gives up its ghost.