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 15608 invoked from network); 4 May 2023 16:07:59 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 4 May 2023 16:07:59 -0000 Received: (qmail 1317 invoked by uid 550); 4 May 2023 16:07:56 -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 1279 invoked from network); 4 May 2023 16:07:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1683216463; x=1685808463; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Eo+rkgFhLqIyTSVlX7XZLHC1Q0fwKlEXV2Rl9dgKvuc=; b=xrg5EsNqfUBdCVgR2RL9niKK/QDCAjGJZlGlTL5qkA7Nut5acOFCN3DM/h4bNdW5tP 5iVkaOvyTzbb0xH5XdDC6BqqWwdpB8LF+AO/FF0bLvDTQkfzOx7hHrXXa+UMcFXbjNwd W0ZGeEsQx8cdTOXDZflX4NuxLxsGNipeowbGiBbDT7MhDvXuynL47tbIN1iMBFmumu4g NGMqrcgE+mRyGAL64Xi8cdKqkID8cGpx3WQzuiJ5k55nEUlJr3c9KdMkawCNVgyzUA5p XlecpvTF0Jl7G5b73dNGAwUjFgdeZh8wRI5tW0r6YZHAPbl0GWj1r8m7151/z6v6hXq7 6EZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683216463; x=1685808463; 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=Eo+rkgFhLqIyTSVlX7XZLHC1Q0fwKlEXV2Rl9dgKvuc=; b=g2/eQ+8kU4WbpBZaN+fHgQKxVMWOlM95ng0UgFP8wMUHG25DZXlNzcW2ju40C+gGah irgjnGUiRztjE37cyhy/moU4qpzZnIOXtdOuizWSnaloqGhWUhbPkWsRQeqgvpnX9ojp FUF2vCbiuxW+5xHOyq/p1Y9MODAuALPnXizroxi0piCVn5S8JoGiL/XwcH+jhwFlIzoz klW/v+vcOaFAoIUi/h0NqNKCy0vtwrs5Ug6eGNzBTOlrCdNSgLjyr8ANkjcg4jLgYlUL PkpElx87JbYH0DUX/en+nfH4TR6VGYxsFSIwtdqY1/iHSvwwgXRHEH7rQEuuwoa87R0M xXvQ== X-Gm-Message-State: AC+VfDzWL/EpOHovZ5sfqJBO2Mv+cQvIqt6D1H3IY42oEPmSR/sCTP+n Q+AKK9exdlZ3ners0s0NR2aJ7YffNlX8Xqnq5rdYgg== X-Google-Smtp-Source: ACHHUZ4CgeS4gYeaeXL6gg4H3zfk0r8/GjlO5rt9hmIol+QCnYEkw6AOF5d7Khf4ph7s41ei4xYzpr40QiRx2kscjYc= X-Received: by 2002:a05:6a00:1a8d:b0:63f:ffd:5360 with SMTP id e13-20020a056a001a8d00b0063f0ffd5360mr3182122pfv.21.1683216463301; Thu, 04 May 2023 09:07:43 -0700 (PDT) MIME-Version: 1.0 References: <20220923162518.56284329@inria.fr> <20221119153350.292e390b@inria.fr> <20230504081942.065fc12f@inria.fr> <20230504160304.GC4163@brightrain.aerifal.cx> In-Reply-To: <20230504160304.GC4163@brightrain.aerifal.cx> From: enh Date: Thu, 4 May 2023 09:07:30 -0700 Message-ID: To: Rich Felker Cc: =?UTF-8?B?SuKCkeKCmeKCmyBHdXN0ZWR0?= , musl@lists.openwall.com, =?UTF-8?B?572X5YuH5YiaKFlvbmdnYW5nIEx1byk=?= , Jason Ekstrand Content-Type: multipart/alternative; boundary="00000000000060b80705fae05f29" Subject: Re: [musl] C23 implications for C libraries --00000000000060b80705fae05f29 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, May 4, 2023 at 9:03=E2=80=AFAM Rich Felker wrote: > On Thu, May 04, 2023 at 08:19:42AM +0200, J=E2=82=91=E2=82=99=E2=82=9B Gu= stedt 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. > > > > > 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? > > I'm a little bit hesitant/skeptical to do this in case the optional C > ones eventually end up having requirements that conflict with the > POSIX/extension ones or even just with our/Linux's implementation > choices for them. This seems like locking ourselves into a commitment > to support something that doesn't have a lot of motivation to exist. > only having been involved with POSIX and not WG14, doesn't the latter take existing practice into account like the former does? (if they don't, it seems like anything they declare optional is then _inherently_ non-portable, and so something they'd be better off leaving out! *cough* annex k *cough*) > But I'm open to discussion. > > Rich > --00000000000060b80705fae05f29 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, May 4, 2023 at 9:03=E2=80=AFA= M Rich Felker <dalias@libc.org>= ; wrote:
On Thu,= May 04, 2023 at 08:19:42AM +0200, J=E2=82=91=E2=82=99=E2=82=9B Gustedt wro= te:
> 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 usefu= l,
>
> 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&q= uot; 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?

I'm a little bit hesitant/skeptical to do this in case the optional C ones eventually end up having requirements that conflict with the
POSIX/extension ones or even just with our/Linux's implementation
choices for them. This seems like locking ourselves into a commitment
to support something that doesn't have a lot of motivation to exist.

only having been involved with POSIX and = not WG14, doesn't the latter take existing practice into account like t= he former does? (if they don't, it seems like anything they declare opt= ional is then _inherently_ non-portable, and so something they'd be bet= ter off leaving out! *cough* annex k *cough*)
=C2=A0
But I'm open to discussion.

Rich
--00000000000060b80705fae05f29--