From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) by sourceware.org (Postfix) with ESMTPS id A87433858004 for ; Mon, 31 May 2021 19:28:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org A87433858004 Received: by mail-qt1-x82b.google.com with SMTP id t20so8574768qtx.8 for ; Mon, 31 May 2021 12:28:17 -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=ZTUKTClanFohYxKZ77fimlIzqlKF3lyToNdPxLH5aZ4=; b=FiZ97HHovVKLsmMfwQS49wiCyHsEZYv4fulkq8eYDuem4xthksRsCgIqW2CRqKl4Gx wYSyXrFQusL2oOOfhWRoN1LLop2VPd0Jzr0ZTNf74nvIJ86dtAMO9Iw7kQR6wdS/6c8/ 30N8ngxZXS/j7YReSwW8ZPkU6y+ReuKuRYJp5+ymV4LFEOlAAmX2B5jTAaSucbCOPXg/ jy8w00iB81kv3d5Q3xQKT+asMGrZbapdFg6tM4spZX7EnUrDqFz+Uf2xXv+wGjn5wMBN sRjLitc1a4hUwgMuR7sU2ltildTEb1+BYDuHa9ItoLVwAv0HSv+wwO6ZSarCknlHIUWO DCGw== X-Gm-Message-State: AOAM530kahgr2BzPLE5VagBA7VbvpkfkWVEyckgSC9an74XF2wODhFDx PWfGiPxB2l6nZFFHgsglpFroCAUZujiDtw== X-Google-Smtp-Source: ABdhPJzoCAZZ9VMLPw/Hja+FdMdERHLhS5j8MMv2IQrce3Xy7PN0i3igdXaDaynMHDcfeE+XSccskA== X-Received: by 2002:ac8:7f13:: with SMTP id f19mr15925408qtk.237.1622489297152; Mon, 31 May 2021 12:28:17 -0700 (PDT) Received: from [192.168.1.4] ([177.194.59.218]) by smtp.gmail.com with ESMTPSA id b206sm2926396qkg.103.2021.05.31.12.28.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 31 May 2021 12:28:16 -0700 (PDT) Subject: Re: time64 functions for glibc To: Florian Weimer Cc: Paul Eggert , 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> <87a6oa90ic.fsf@oldenburg.str.redhat.com> From: Adhemerval Zanella Message-ID: <572ae962-5fe8-48e7-2374-86eb61e715f5@linaro.org> Date: Mon, 31 May 2021 16:28:14 -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: <87a6oa90ic.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:28:19 -0000 On 31/05/2021 16:16, Florian Weimer wrote: > * Adhemerval Zanella: > >> We either make it default for all affected architectures or we should >> keep as is, I see not point in making it architecture dependent. > > I'm under the impression that 32-bit Arm is sufficiently different. It might make sense on how a distribution is build and deployed, but I think from glibc point is view regarding LFS and 64 bit time_t support they should be handled the same. > >> 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. > > It's about providing a stack of 32-bit libraries for use by legacy > applications. These libraries are rebuilt from time to time by > distributions and would pick up the changed default, therefore becoming > incompatible with legacy applications. Development work is required to > support both ABIs in one installation. If no one is willing to do the > work (which is what I expect for most of the relevant libraries), for > i386 the more useful choice is the current ABI, to support legacy > applications that can't be recompiled. I don't have a good answer for case where the libraries uses time_t and related types on their own ABI, it would indeed require some work. But at same time if they are bounded by this, these very libraries and application will most likely run in trouble eventually due y2038. I already heard some issue regarding LFS support in the wild, autoconf and other configuration system tries hard to make is default but even then there are cases where they are not used (the BZ#23960 for instance). So I still think making *better* defaults, even if it requires some work from consumers, is better than keep ABIs with either underlying issues or inherent faulty support.