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=-0.8 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_MSPIKE_H2,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 15449 invoked from network); 4 May 2023 16:04:25 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 4 May 2023 16:04:25 -0000 Received: (qmail 29837 invoked by uid 550); 4 May 2023 16:04:22 -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 29804 invoked from network); 4 May 2023 16:04:22 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1683216250; x=1685808250; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=/YuhoR0u+Fl8UUjpdxN4LoLSHDMF6JL30Rmyp4Glg3k=; b=BMGI+UCt9mFB2f2prfPWR7CXv6Gpw465kmBPmFJAZma5egujmjJY8TNrYAbmsMMxwb kOT5nebnHtlv7pfJO+quI2vMj88JivI7U6mrPUnLhnQClfA94k4jFX2KcpHNJHaj+9dw 7Cnbsta25CkSl4YSRLCAh760CcHNJnPE9QVeIiVwhcUxOxkGIJyfok5/bvR1E8D1Xczx xLpvdAHrC3OOkK1sz6ruoXC2K3aDAz+QYfYdbAqn+J9HtExQa9owcGk6FOIGoyLaOXZq vfZy3JTdPQBduTrwNNWa2D7lC/PgiR9xTU8j/8844h18ebswzrPH01MnjVZfQoeyOqJi 2E+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683216250; x=1685808250; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=/YuhoR0u+Fl8UUjpdxN4LoLSHDMF6JL30Rmyp4Glg3k=; b=Pd8mmmg1azE+BSRNBa+jJhIj3RYVQutZcoH22iY+ejMgEp38drhSHC9/WdlBWjxR71 v+sFW4TYm0jmIOaX92atI8LNYWFx8XOdTvPZrNFgT8eBhdfUao8Z1k1pa8vicLW678qt 6QslPecXJbaojlpBdZMK66S+UUjsBfeJs5RJNMtHtWNdpuOljk3NKGxjtoLKRV4TUf4u Izpn13RaARnwflnbnbSeZD1c67cH/KF5mchqpwvfE778UTGq3KxiuqoNMcuoG5MGvO58 S9egUI+pTJDG8B8Re3WNQZlLXh9uxjuvBXR7feyQmZO9GYgm/qPhSXaWyW+pseLlUZgd dh1g== X-Gm-Message-State: AC+VfDzoWy+yu8rzX7QphlsZ57rAyEYBw6Cj9cp8nWz1cnBVojhqzct7 uiF/SrT1SmZV/vb0wUOX2+gjA7bU0sGoO7cE0FwIvA== X-Google-Smtp-Source: ACHHUZ79iMqeLwnE/2V5jWXZ1oJWwJw5Yyj4WVv7pPEUNU22OKJJx+2oH8T02T9nxKzGiTtNCKdz+R6hYT+l6aSdvy0= X-Received: by 2002:a05:6214:1c8f:b0:61b:6e71:99b with SMTP id ib15-20020a0562141c8f00b0061b6e71099bmr10812898qvb.18.1683216249603; Thu, 04 May 2023 09:04:09 -0700 (PDT) MIME-Version: 1.0 References: <20220923162518.56284329@inria.fr> <20221119153350.292e390b@inria.fr> <20230504081942.065fc12f@inria.fr> In-Reply-To: <20230504081942.065fc12f@inria.fr> From: enh Date: Thu, 4 May 2023 09:03:58 -0700 Message-ID: To: =?UTF-8?B?SuKCkeKCmeKCmyBHdXN0ZWR0?= Cc: musl@lists.openwall.com, =?UTF-8?B?572X5YuH5YiaKFlvbmdnYW5nIEx1byk=?= , Jason Ekstrand Content-Type: multipart/alternative; boundary="000000000000a3f6c205fae052aa" Subject: Re: [musl] C23 implications for C libraries --000000000000a3f6c205fae052aa Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, May 3, 2023 at 11:19=E2=80=AFPM J=E2=82=91=E2=82=99=E2=82=9B Gusted= t wrote: > Hi, > > on Wed, 3 May 2023 15:58:26 -0700 you (enh ) 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. > sure, but the more esoteric the clocks, the less likely _that_ part is to be portable anyway. > > 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? https://android-review.googlesource.com/c/platform/bionic/+/2576754 > The particular choices of values become > part of the ABI, sort-of. So it would be better to be consistent > between implementations. > are there any two linux libcs that are abi compatible? i didn't think so. > Would this motivate musl to accept patches for the optional bases that > come with C23? Or maybe the whole set? > i think bionic and musl are philosophically quite different there --- musl seems to try to stick to the exact letter of ISO/POSIX, whereas with bionic i accept that for everything you can possibly imagine, _someone_ will be trying to do it, and -- unless you're actually going to prohibit it via selinux/seccomp for security or privacy reasons -- i may as well make it as minimally painful as possible. > Thanks > J=E2=82=91=E2=82=99=E2=82=9B > > -- > :: ICube :::::::::::::::::::::::::::::: deputy director :: > :: Universit=C3=A9 de Strasbourg :::::::::::::::::::::: ICPS :: > :: INRIA Nancy Grand Est :::::::::::::::::::::::: Camus :: > :: :::::::::::::::::::::::::::::::::::: =E2=98=8E +33 368854536 > <+33%203%2068%2085%2045%2036> :: > :: https://icube-icps.unistra.fr/index.php/Jens_Gustedt :: > --000000000000a3f6c205fae052aa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, May 3, 2023 at 11:19=E2=80=AF= PM J=E2=82=91=E2=82=99=E2=82=9B Gustedt <jens.gustedt@inria.fr> wrote:
Hi,

on Wed, 3 May 2023 15:58:26 -0700 you (enh <enh@google.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.

sure, but the more esoteric the clocks, the less likely _that_ part is t= o be portable anyway.
=C2=A0
> 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?

=C2=A0
The particu= lar choices of values become
part of the ABI, sort-of. So it would be better to be consistent
between implementations.

are there any = two linux libcs that are abi compatible? i didn't think so.
= =C2=A0
Would this motivate musl to accept patches for the optional bases that
come with C23? Or maybe the whole set?

= i think bionic and musl are philosophically quite different there --- musl = seems to try to stick to the exact letter of ISO/POSIX, whereas with bionic= i accept that for everything you can possibly imagine, _someone_ will be t= rying to do it, and -- unless you're actually going to prohibit it via = selinux/seccomp for security or privacy reasons -- i may as well make it as= minimally painful as possible.
=C2=A0
Thanks
J=E2=82=91=E2=82=99=E2=82=9B

--
:: 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 ::
--000000000000a3f6c205fae052aa--