From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa2.mentor.iphmx.com (esa2.mentor.iphmx.com [68.232.141.98]) by sourceware.org (Postfix) with ESMTPS id 61A7C385483E; Thu, 29 Oct 2020 15:43:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 61A7C385483E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=joseph_myers@mentor.com IronPort-SDR: pNCBIfV+CIqHaejB2CsvjcCrHX3kujOHDD8htJ9aa0ppqDOa8i8Yh+QJniYRRihNY+6leTWnud Q9l394iCZheciWVHyoE+8RZGBXiAIu0ApbQvsm+LbreiVdY/h8BfmneFP+qeZ8BDl08iDfY9Fj HuvaRerS/k5uF2DA0MANd/QjX73WU8vlNqIGuYyUJjsH1EhYBOlPdmWOAQWhZ2c+DlRvVE5TCZ +7/bzwW0UroywGbx5QmSaTWas0sbrT15lqH3lKB796EXPd4SVzHvutxYWSk+MfkQFBRLfbsjv/ vJY= X-IronPort-AV: E=Sophos;i="5.77,430,1596528000"; d="scan'208";a="54545357" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa2.mentor.iphmx.com with ESMTP; 29 Oct 2020 07:43:21 -0800 IronPort-SDR: 0fPQJTdoN9dGNJX7YJlCIDOzKDcfiWgrdVCUeCtREBsgO+K1vZwPrEkTvSCcl6txppRK2FiESV zI/XF3jMxtPSqFBW4mhC6vseGnaBEDa0hMwDGNpxbr3Qepni36ZI58x3ZK+ky4hhC/As9W3VN6 vZ1xgf7+fLh58ghGPQ4ymBPw/aNw6823Oj1LwNyIulerzx72D68t27PRmoOSzDEClVurqDWERl VvFvSbv+Y5bzT7Y0anVkzdGMqET/dWUPfB3E7FssW98ZlR1Da9Llg6W+NZXP18tMAbHkxrUsvz s+8= Date: Thu, 29 Oct 2020 15:43:14 +0000 From: Joseph Myers X-X-Sender: jsm28@digraph.polyomino.org.uk To: Lukasz Majewski CC: libc-help , Florian Weimer , Alistair Francis , , Andreas Schwab Subject: Re: [Y2038] Question about porting y2038-tests to glibc In-Reply-To: <20201029104404.6b1fc1d7@jawa> Message-ID: References: <20201028110156.747fb676@jawa> <20201029104404.6b1fc1d7@jawa> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: svr-ies-mbx-09.mgc.mentorg.com (139.181.222.9) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) X-Spam-Status: No, score=-3126.3 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, RCVD_IN_DNSWL_LOW, SPF_HELO_PASS, 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-help@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-help mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2020 15:43:24 -0000 On Thu, 29 Oct 2020, Lukasz Majewski wrote: > > I think any tests requiring changing the system clock are unsuitable > > for the glibc testsuite > > I think that they are necessary, as most errors are visible after some Not all tests that may be useful for testing a feature, or necessary for making sure it works before it's added to glibc, are suitable for inclusion in the glibc testsuite. The glibc testsuite needs to avoid perturbing global system state. (There are sometimes other reasons a test is, although useful, unsuitable for inclusion. For example, anything related to using glibc headers with compilers that aren't supported for building glibc itself isn't suitable for the normal glibc testsuite.) > > without _TIME_BITS=64. (Tests of interfaces doing things requiring > > privileges, such as setting the system clock, may only verify that a > > call to such a function can be compiled and linked, not that it does > > anything useful at runtime.) > > Could you elaborate on this idea? Is there any test in glibc which only > checks if function can be compiled and linked? Wouldn't this be too > little to prevent regression? I don't have a specific example of such a test, but there have been several instances in the past where a function was accidentally missing from some architectures (or, although compiled into libc, had no symbol version set and so could not actually be linked against), which provides clear evidence that if we can't test anything more about a function (because it requires privileges) it's still useful to test that the function is actually present and a call can be compiled and linked. -- Joseph S. Myers joseph@codesourcery.com