[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230504081942.065fc12f@inria.fr>
Date: Thu, 4 May 2023 08:19:42 +0200
From: Jₑₙₛ Gustedt <jens.gustedt@...ia.fr>
To: enh <enh@...gle.com>
Cc: musl@...ts.openwall.com, "罗勇刚(Yonggang Luo)"
<luoyonggang@...il.com>, Jason Ekstrand <jason@...kstrand.net>
Subject: Re: C23 implications for C libraries
Hi,
on Wed, 3 May 2023 15:58:26 -0700 you (enh <enh@...gle.com>) wrote:
> (i share others' skepticism that timespec_get() is very useful,
I don't think that these interfaces by themselves are the most
interesting. The original motivation to create these interfaces stem
from the creation the integration of threads in to the C standard. And
there the monotonic and thread-specific clocks make all their sense.
But also having process cpu usage in a well-defined interface (`clock`
usage is not portable for that) is a win.
> and especially that non-ISO bases will ever be useful to anyway, but
> i like the idea of allowing future additions to "just work" with an
> old libc enough that i've implemented bionic's
> timespec_get()/timespec_getres() in this style.)
Great!
Do you have a link to that? The particular choices of values become
part of the ABI, sort-of. So it would be better to be consistent
between implementations.
Would this motivate musl to accept patches for the optional bases that
come with C23? Or maybe the whole set?
Thanks
Jₑₙₛ
--
:: ICube :::::::::::::::::::::::::::::: deputy director ::
:: Université de Strasbourg :::::::::::::::::::::: ICPS ::
:: INRIA Nancy Grand Est :::::::::::::::::::::::: Camus ::
:: :::::::::::::::::::::::::::::::::::: ☎ +33 368854536 ::
:: https://icube-icps.unistra.fr/index.php/Jens_Gustedt ::
Content of type "application/pgp-signature" skipped
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
