From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 10543 invoked from network); 5 May 2023 06:40:40 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 5 May 2023 06:40:40 -0000 Received: (qmail 29737 invoked by uid 550); 5 May 2023 06:40:36 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 29700 invoked from network); 5 May 2023 06:40:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inria.fr; s=dc; h=date:from:to:cc:subject:message-id:in-reply-to: references:mime-version; bh=FMRJxYcCRtU+bwRBxzjdhqBLbPxJdAtffkT8QYSCKuM=; b=h4OSvBiB3n5l3mysaOe7iB2M721WIuUg0xaJUrNGxd7ZP9zhepVYex4e G5FQ2T/ZfVgjkWJnMRYDLukb4/MbZUgSKg8dBVonUhUVu6y6V+tNuHRue WHjtREuQRo1dzEJakNgFyiyQKi4BII1tIgOmacmmyNxrfkHcCnTjvsisN 4=; Authentication-Results: mail2-relais-roc.national.inria.fr; dkim=none (message not signed) header.i=none; spf=SoftFail smtp.mailfrom=jens.gustedt@inria.fr; dmarc=fail (p=none dis=none) d=inria.fr X-IronPort-AV: E=Sophos;i="5.99,251,1677538800"; d="scan'208";a="106391974" Date: Fri, 5 May 2023 08:40:23 +0200 From: =?UTF-8?B?SuKCkeKCmeKCmw==?= Gustedt To: enh Cc: Rich Felker , musl@lists.openwall.com, " =?UTF-8?B?572X5YuH5Yia?=(Yonggang Luo)" , Jason Ekstrand Message-ID: <20230505084023.0b56332c@inria.fr> In-Reply-To: References: <20220923162518.56284329@inria.fr> <20221119153350.292e390b@inria.fr> <20230504081942.065fc12f@inria.fr> <20230504160304.GC4163@brightrain.aerifal.cx> Organization: inria.fr X-Mailer: Claws Mail 4.0.0 (GTK+ 3.24.33; x86_64-pc-linux-gnu) X-Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAAXNSR0IArs4c6QAAACRQTFRFERslNjAsLTE9Ok9wUk9TaUs8iWhSrYZkj42Rz6aD3sGZ MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/j3GmDeVRY=MBowDK7rn1A=b"; protocol="application/pgp-signature"; micalg=pgp-sha1 Subject: Re: [musl] C23 implications for C libraries --Sig_/j3GmDeVRY=MBowDK7rn1A=b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable enh, on Thu, 4 May 2023 09:07:30 -0700 you (enh ) wrote: > only having been involved with POSIX and not WG14, doesn't the latter > take existing practice into account like the former does? In this case WG14 considers the POSIX interfaces as existing practice. We just have the problem that unfortunately in the past it was decided not to map the full feature set of the clock interfaces into C, but to somehow rename and reduce things to these `timespec` interfaces. (I was not yet there, then, but my understanding is that this was added a bit in a hurry relatively late in the process for C11.) The argument that convinced WG14 to take in these three new optional time bases is to avoid diverging practice in the future. So if somebody adds a monotonic clock (for example) to a C implementation, it should have the semantics as described. And something like that (a monotonic clock) has for example been sought by users for the thread interfaces that use time limits. Thanks J=E2=82=91=E2=82=99=E2=82=9B --=20 :: ICube :::::::::::::::::::::::::::::: deputy director :: :: Universit=C3=A9 de Strasbourg :::::::::::::::::::::: ICPS :: :: INRIA Nancy Grand Est :::::::::::::::::::::::: Camus :: :: :::::::::::::::::::::::::::::::::::: =E2=98=8E +33 368854536 :: :: https://icube-icps.unistra.fr/index.php/Jens_Gustedt :: --Sig_/j3GmDeVRY=MBowDK7rn1A=b Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQSN9stI2OFN1pLljN0P0+hp2tU34gUCZFSk1wAKCRAP0+hp2tU3 4iyMAJ9G/pyE7IfM1UqZqI5PNWexy8BYCgCeKfXc6sqq0KR9x8ybt103s6aFi4o= =d2ge -----END PGP SIGNATURE----- --Sig_/j3GmDeVRY=MBowDK7rn1A=b--