From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS3215 2.6.0.0/16 X-Spam-Status: No, score=-3.8 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI, SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 994221F8C6 for ; Mon, 16 Aug 2021 22:33:17 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 1F7DD3844051 for ; Mon, 16 Aug 2021 22:33:16 +0000 (GMT) Received: from esa2.mentor.iphmx.com (esa2.mentor.iphmx.com [68.232.141.98]) by sourceware.org (Postfix) with ESMTPS id 797173854803 for ; Mon, 16 Aug 2021 22:33:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 797173854803 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com IronPort-SDR: OeqEwvnN5NEomDWDG7nvO7/SdnvV2uwaN0966kDqwh58sJXVa/1565lyMmcjKAaGOzNMu+smU/ a4piTcPKyHOWpcgqd6Gf6FbGfgT2P2i//aHR7L1qCRQglMkA3cnixvasP92v96XlO2LN5rWDOx 4Rg5c3FHXWY90hw9+1udQb3BxaZuDgD/ACHjpnRUuf70gc9gdsQ+mNB7W+mcMzfIHguRs18Tf/ 2vbl5ZimU+WHZoximbKTWmMbceJi0urHPNPo3EFCyL2TmxOAAnripv31KnGIZnauzxh1Ofq1iZ ENaX3dMV+Ccu9sE1xyPIc60F X-IronPort-AV: E=Sophos;i="5.84,327,1620720000"; d="scan'208";a="64763979" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa2.mentor.iphmx.com with ESMTP; 16 Aug 2021 14:33:04 -0800 IronPort-SDR: +4vJYsUsmpmenL0/N9E+IP5/3SbGF/DdApkg2WWWwCPdYDvTlX27kKFLYfa6upUyWzWFW++P+5 xgEwuaHQoUO+1Ju64IIdkjWPohLPPYrx8GMdzOfrtdUiSFlz7ZgDhe2W+rvNEzkOIRph9k12Ra y3sa9Xk9iT8Qk9LMYvalZz3Nw01b7nT5tH5k1RDAQL+bLFJ8jHc2GxBvhMi342T8tgiv/oFhIr 3FhAYzMfHeMKpvf2Eph9FGpnilkUGypmI01JENq5Wuecj+jS99VlI22whC4QFhFP3HdPCQeUyj upo= Date: Mon, 16 Aug 2021 22:32:59 +0000 From: Joseph Myers X-X-Sender: jsm28@digraph.polyomino.org.uk To: Stafford Horne Subject: Re: [PATCH v2] time: Fix overflow itimer tests on 32-bit systems In-Reply-To: Message-ID: References: <20210806094217.3227877-1-shorne@gmail.com> <0f577bc8-bef8-6c06-aaa9-57bf16d8443b@linaro.org> 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-08.mgc.mentorg.com (139.181.222.8) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) 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: , Cc: Openrisc , GLIBC patches Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org Sender: "Libc-alpha" On Tue, 17 Aug 2021, Stafford Horne via Libc-alpha wrote: > Should we provide __KERNEL_OLD_TIMEVAL_MATCHES_TIMEVAL64 for not linux builds, > or remove __KERNEL_OLD_TIMEVAL_MATCHES_TIMEVAL64 from the itimer test again? > The reason for using __KERNEL_OLD_TIMEVAL_MATCHES_TIMEVAL64 is to pick up the > timeval size which is different on each architecture. I'd suggest having a macro that doesn't refer to either "kernel" or "old timeval" (and that is defined for both Linux and Hurd). As far as I understand, the logical concept that's relevant for this test isn't either one of those, it's more like "setitimer supports times that cannot be represented in 32 bits". -- Joseph S. Myers joseph@codesourcery.com