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 [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id BEC9E3858004 for ; Mon, 31 May 2021 18:57:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org BEC9E3858004 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-497-IcoFjRJBNL2yB5GcisK40g-1; Mon, 31 May 2021 14:56:58 -0400 X-MC-Unique: IcoFjRJBNL2yB5GcisK40g-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 26233802939; Mon, 31 May 2021 18:56:57 +0000 (UTC) Received: from oldenburg.str.redhat.com (ovpn-113-228.ams2.redhat.com [10.36.113.228]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 925155D9D0; Mon, 31 May 2021 18:56:55 +0000 (UTC) From: Florian Weimer To: Paul Eggert Cc: Adhemerval Zanella , Elmar Stellnberger , libc-maintainers@gnu.org, libc-alpha@sourceware.org Subject: Re: time64 functions for glibc References: <8bb369a7-ebc0-d108-ca38-0ba2c658df12@elstel.org> <216b19de-ecf1-91a2-bea0-4af829414788@cs.ucla.edu> Date: Mon, 31 May 2021 20:56:53 +0200 In-Reply-To: <216b19de-ecf1-91a2-bea0-4af829414788@cs.ucla.edu> (Paul Eggert's message of "Mon, 31 May 2021 11:46:09 -0700") Message-ID: <87eedm91fu.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-6.7 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 May 2021 18:57:01 -0000 * Paul Eggert: > On 5/31/21 9:01 AM, Adhemerval Zanella via Libc-alpha wrote: >> It is on 2.34 plan [1], Carlos O'Donnel is reviewing it. Similar to LFS, >> you will need a newer flag to actually enable it (-D_TIME_BITS=64). > > One place where Microsoft got it right and we're arguably getting it > wrong, is that 64-bit time_t is the default on 32-bit MS-Windows, > where one must opt into 32-bit by #defining _USE_32BIT_TIME_T. > > It's too late in 2.34 to make 64-bit time_t the default, but we should > at least document that 64-bit time_t is planned to be default in the > future. That is, programmers should not *rely* on 32-bit being the > default. I strongly object to that for i386-linux-gnu. It's pretty much for compatibility with legacy applications at this point, and changing the default will only make it harder for distributions to support legacy use. Software that can be recompiled (and thus switch to 64-bit time_t) really should be ported to a 64-bit architecture. I don't have an opinion about what people to do with 32-bit Arm. Thanks, Florian