From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) by sourceware.org (Postfix) with ESMTPS id 11DF03939C34 for ; Mon, 31 May 2021 19:08:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 11DF03939C34 Received: by mail-qk1-x732.google.com with SMTP id k4so12086820qkd.0 for ; Mon, 31 May 2021 12:08:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=wlFv3GI2JwULyFUYIY5jVAUDRPd8aYNMyArU0WmgCls=; b=nhQkyY/ceOJ5yE8k3IWTUqlogaApUEDudA6ZX+KZ0Mx1y8IDEoANlYMrS+ffLAxfIM 3LX36RLl5DTNmfXf9OosVZioqJfXWW0BSAMmPvTF19dcy2WsFVxzrg+ug+jm7zdMHNqk UCpzTnLHdIgiHRWGlxV5ohI1MqSdG65+BOf2RNwcgk4HHvQ4g5L7ww5zMY//9yYD5rNk u6WUrkHZ1uoCuCUSAZ9X/9iRhD6vgwzNjt8PyHpjNuxHQklZcoIhthBDjl/u/JpIyKxh 4jYzRlkv9QFJvE+YdTUA0h56pJL7dFUT0V51PQKlraPozzH7QzhrmOSKQg9lx3ByCwdY Jdfw== X-Gm-Message-State: AOAM531JnyajAvIwNT6OnSjyQ6bP5QOTzY1UKgzxSS+I9cs458AaV/rb RmdN9bpayDw2Fs+RmBs5ycxdcj6Soixppw== X-Google-Smtp-Source: ABdhPJy1vvNnQ6mX2iV8/rBMCY/Mcx5TsFaORnKp02Fl9PIDPN+86wa4Z62J98oDDfO0e+jP3XxnmQ== X-Received: by 2002:a05:620a:1521:: with SMTP id n1mr4623509qkk.426.1622488107448; Mon, 31 May 2021 12:08:27 -0700 (PDT) Received: from [192.168.1.4] ([177.194.59.218]) by smtp.gmail.com with ESMTPSA id d18sm9855946qkc.28.2021.05.31.12.08.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 31 May 2021 12:08:27 -0700 (PDT) Subject: Re: time64 functions for glibc To: Florian Weimer , Paul Eggert Cc: Elmar Stellnberger , libc-maintainers@gnu.org, libc-alpha@sourceware.org References: <8bb369a7-ebc0-d108-ca38-0ba2c658df12@elstel.org> <216b19de-ecf1-91a2-bea0-4af829414788@cs.ucla.edu> <87eedm91fu.fsf@oldenburg.str.redhat.com> From: Adhemerval Zanella Message-ID: Date: Mon, 31 May 2021 16:08:24 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: <87eedm91fu.fsf@oldenburg.str.redhat.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, 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 19:08:29 -0000 On 31/05/2021 15:56, Florian Weimer wrote: > * 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. We either make it default for all affected architectures or we should keep as is, I see not point in making it architecture dependent. And I don't see your point here: if the legacy is being recompiled it is in essence not in compatibility mode. We really need to move from non-LFS and 32-bit time_t interfaces. > > I don't have an opinion about what people to do with 32-bit Arm. > > Thanks, > Florian >