From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) by sourceware.org (Postfix) with ESMTPS id 61C32394EC02 for ; Mon, 8 Mar 2021 13:12:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 61C32394EC02 Received: by mail-qt1-x82f.google.com with SMTP id h9so7391916qtq.7 for ; Mon, 08 Mar 2021 05:12:59 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:references:from:subject:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=M0dRkcYM+js7UeMD/tITNrCJfhZMPLRhx+zivFYUhdo=; b=hN12Fic2Imqv+lnVIT/QiJ4qZwbSUT6PvGh7tPZKy3VWQQZwzztustU4xfu8294Kqr HGabCIuUJeo8MtfyhkrTTgs+PNJgnPvs/mlSvTW3SPAiuSPFs1BjAbO7TRfIbWJp3n3b jdzOy9ttypB/fCK2OyfbVGMu+ZjZYcl4hwwalFeyiwXJtX/+BPktXHNLpRCi6YWdAhHw HQSoF2znwn06jcMciByQ5xNKfrwDZDauIXlX2HLo4VHfXXbZJq49xoZJm69sxgWS9l0e KBbWNCGkIue+fvqJGGtYmY4UqeCaywuDmPg6RmLNNnfznWeYwUPFSmBMFsfKPTxLmfWK N22g== X-Gm-Message-State: AOAM531QUF0S6a2IwFsTjKnqr8ZMRuI96b3bxHh8GF+NiS70PlPdS18B ic8hNTudgq2IRhMWcxorDiBZhN6zqsNBSQ== X-Google-Smtp-Source: ABdhPJyW7ZbeeP40t9e7+LX0wIi5/YEYFZzCNgh/K6uvtvqPrOqN90UCZ5+wpTuWY/OWv/YRogjVkw== X-Received: by 2002:ac8:3981:: with SMTP id v1mr9576472qte.183.1615209178543; Mon, 08 Mar 2021 05:12:58 -0800 (PST) Received: from [192.168.1.4] ([177.194.48.209]) by smtp.googlemail.com with ESMTPSA id s24sm7538126qks.127.2021.03.08.05.12.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 08 Mar 2021 05:12:58 -0800 (PST) To: Joseph Myers Cc: libc-alpha@sourceware.org References: <20210305201518.798584-1-adhemerval.zanella@linaro.org> <20210305201518.798584-45-adhemerval.zanella@linaro.org> From: Adhemerval Zanella Subject: Re: [PATCH 44/52] y2038: Add test coverage Message-ID: <7f5d3b0a-30b6-876d-02db-4c4e88022d36@linaro.org> Date: Mon, 8 Mar 2021 10:12:55 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.5 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, 08 Mar 2021 13:13:01 -0000 On 05/03/2021 21:13, Joseph Myers wrote: > On Fri, 5 Mar 2021, Adhemerval Zanella via Libc-alpha wrote: > >> It is enabled through a new rule, tests-y2038, which is built only >> when the ABI supports the comapt 64-bit time_t (defined by the >> header time64-compat.h, which also enables the creation of the >> symbol Version for Linux). It means the tests are not built >> for ABI which already provide default 64-bit time_t. > > I'm not convinced it's correct not to build them for ABIs that already > have 64-bit time_t. _TIME_BITS=64 should work, and do nothing, for such > ABIs; it seems useful to build and run the tests to verify that the > headers don't have any incorrect redirections in that case, for example. I was not sure about enabling or not the tests for ABI with already support 64 bit time as default (my initial approach was to enable them to all ABIs). If we prefer, I can re-enabled it regardless. I disabled because of two reasons: 1. Different than LFS where redirections does happen for ABI with 64-bit off_t as default; _TIME_BITS=64 is really a no-op for such ABIS (there is no redirection involved, neither any new type or type redefinition). It means that issues on 64-bit time_t default ABI that might happen will mostly likely trigger build issues (like type mismatch or symbol redirection to nonexistent symbol). It also speed up the glibc test on such architectures. 2. It is simpler to handle systems (Hurd) that do not support 64-bit time_t as well. > > (On the other hand, if any systems - Hurd? - don't get support for 64-bit > time, it's correct not to build the tests for such systems.) > The patch already does it.