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=-4.0 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI, NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 30199 invoked from network); 4 May 2023 23:16:18 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 4 May 2023 23:16:18 -0000 Received: (qmail 30191 invoked by uid 550); 4 May 2023 23:16:15 -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 30152 invoked from network); 4 May 2023 23:16:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683242163; x=1685834163; h=in-reply-to:from:references:cc:to:content-language:subject :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=2s8JX7Oo7Kgi09ThTGGL8nFPKAKyCWQHaAh8FI3dAs0=; b=LNywU2uX4+RyGl4WFJ95uJTJrJIjIXVXZH2rCBQHY1qAyTdUB/EIk7LU6t8JVUrlG9 HAphrp5zvemvuzcbFt19Ybn+8YaIMvMbBp+VOamXQhJ+U56IIYaxf3qvf9zM7XjHZY0y Z8RCc0OP1E51v+shdPO7//+03f8HjUm0cBCtUG0FyIAtC5bBw4qKX1hxjv1sqM/x8xFO 38f8BwrEWZGP5uGQVOicYP1DVuZB4ezPbkVR/luGRGCrWreDnEiIMrqImRjr5CoySqGX sbPrrOM+flhFYlBsb7UPk420GC+PDLCA/JkYNHGW7rZpr4Ka2sCtJxxcDWr0iZybR/Z1 vaqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683242163; x=1685834163; h=in-reply-to:from:references:cc:to:content-language:subject :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=2s8JX7Oo7Kgi09ThTGGL8nFPKAKyCWQHaAh8FI3dAs0=; b=E5E68BN+WOIOcH8o7E+omPpn6gCuMNGeqLEq8mpEdH4MR1CweUuOiYz9fuLs6W10BT r7/5H21iymgYL9YkgrzpeJLxZaMHA/dcKdxTSlJpJGiw0q1hHpu3X42tf7HIY0Yj9CaM 3y8TJhw4byAES0NDUiVa2IxjsVDwJIZxVsh5ZFIUnDnp7mKS3bE5POdETT4IiPzgTCka IAtdK1LWPu4s25cuIDRPSDGbAhNALL8WdN2vu+FnIw1yGugSaGZ+YNXhFxDaIhZpVYUx Sit+4Q7xqWkpyzA774bzrSbc8Tnx3vv+sSw6xqcQp5YBFcyYn5hXW7XK4xgZ743KTtU7 Ah5Q== X-Gm-Message-State: AC+VfDztv0mwLObFa/LvBm87vv2RrCmOk9aipcNg1RzG/vgwQbEe+J8A lQ90KtTv0xxPWbbXQ/esuqQ8eeQSJ0pCKPFa X-Google-Smtp-Source: ACHHUZ4NoAIodHqr78o074xrdghmF5F7w7zUqNmTE8EuDp7T8Ev0Iz6jlfjoW77vvId4Y0deRBZ7gg== X-Received: by 2002:a05:6402:1aca:b0:50b:fbb5:f934 with SMTP id ba10-20020a0564021aca00b0050bfbb5f934mr2747958edb.3.1683242163190; Thu, 04 May 2023 16:16:03 -0700 (PDT) Content-Type: multipart/alternative; boundary="------------AdakY0SqjdzTxC8ffiHIa2mC" Message-ID: <9ecc996a-5eba-404d-1b95-63398ea93543@gmail.com> Date: Fri, 5 May 2023 01:16:01 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Content-Language: en-US To: musl@lists.openwall.com, enh , Rich Felker Cc: =?UTF-8?B?SuKCkeKCmeKCmyBHdXN0ZWR0?= , =?UTF-8?B?572X5YuH5YiaKFlvbmdnYW5nIEx1byk=?= , Jason Ekstrand References: <20220923162518.56284329@inria.fr> <20221119153350.292e390b@inria.fr> <20230504081942.065fc12f@inria.fr> <20230504160304.GC4163@brightrain.aerifal.cx> From: Gabriel Ravier In-Reply-To: Subject: Re: [musl] C23 implications for C libraries This is a multi-part message in MIME format. --------------AdakY0SqjdzTxC8ffiHIa2mC Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 5/4/23 18:07, enh wrote: > > > On Thu, May 4, 2023 at 9:03 AM Rich Felker wrote: > > On Thu, May 04, 2023 at 08:19:42AM +0200, Jₑₙₛ Gustedt 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*) Clearly this isn't the case for at least some things they declare optional, unless you think types like uint32_t or uintptr_t are useless. In any case, I'm pretty sure they take existing practice into account - for example, stuff like the %B specifier are technically optional given that the uppercase conversion specifier namespace wasn't reserved, but iirc there's no known implementation of C that uses it for any other purpose. > > But I'm open to discussion. > > Rich > --------------AdakY0SqjdzTxC8ffiHIa2mC Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 5/4/23 18:07, enh wrote:


On Thu, May 4, 2023 at 9:03 AM Rich Felker <dalias@libc.org> wrote:
On Thu, May 04, 2023 at 08:19:42AM +0200, Jₑₙₛ Gustedt 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.
>
> > 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*)
Clearly this isn't the case for at least some things they declare optional, unless you think types like uint32_t or uintptr_t are useless. In any case, I'm pretty sure they take existing practice into account - for example, stuff like the %B specifier are technically optional given that the uppercase conversion specifier namespace wasn't reserved, but iirc there's no known implementation of C that uses it for any other purpose.
 
But I'm open to discussion.

Rich


--------------AdakY0SqjdzTxC8ffiHIa2mC--