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 30068 invoked from network); 4 May 2023 23:12:08 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 4 May 2023 23:12:08 -0000 Received: (qmail 18060 invoked by uid 550); 4 May 2023 23:12:05 -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 18012 invoked from network); 4 May 2023 23:12:04 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683241913; x=1685833913; h=in-reply-to:from:content-language:references:cc:to:subject :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=cO+1FnIk7d/7NmuS2lSwfTQu6qwCgkUudO80UwpKm5o=; b=RCFMbZAGEMtm6sT5O/OD5eBnGczulUVdDMollKNBErr96TsMZk9falW2yVT2IlNaSY jak9tEYYt+woP1ru/87MCblwylbmYvkZvucbjGrN/I4DnliwiIsQ+tfhUt8TXaCwk+2L 6ra5kVTEVpXAMcJ5fRU0NNH12R+J0i/y07jFVk4LrSAieLk845qwRa4Zlf366BloKMmk hS0WlNP9tXqGUdNlwts8L+IHy+WZQa6Au5/RhxGKQGorZdnYbF1kgpOpseQoYjSy6d+V ch09Y9t7hzEJGTajvwTAbPCNGsFkee38A8JvK1m26AXKMf3SqXHHOc5aYQp8co9CmZ6s m4NQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683241913; x=1685833913; h=in-reply-to:from:content-language:references:cc:to:subject :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=cO+1FnIk7d/7NmuS2lSwfTQu6qwCgkUudO80UwpKm5o=; b=Lw1AG9dHAMuSov2wpXwLs3ELPvOTh+UMyU7LPl7ETgsd2IBWWYFGJWJJ3dFEp0od3q BG332Kva8JfHJIMRfTLKz6fhwiQJ4kqrZ12XeOzn8BOCG1M+515IlUE3rFf1GOQA3VAm pyEnJ3e0GtryuJqCqZsHBF8lsaMVg/z3X90T5cXEczdrLK6ICqFmoiKE05drbfYMvhPI j8qnrmVkCIeIO0AC3EyLXKPXPndgGUc7ohb8VRCuNm1/bXJKIwUfpCKS3XHjUEM5ewRp FMSR9J5MPhL2w4bD1/FfyeBKU5IGTOCZRdlarEZ+iFNcQ/XN2E6G4kNPsWmpzByYfJ3Y UC+g== X-Gm-Message-State: AC+VfDwC5F+Bt6UqSsWLcG9AbJAgpDdsYnc2+GYsAlTBC1fM01iPijbD rO6LUxcqmklPe23LsMczGy7rihu5czbc/6CG X-Google-Smtp-Source: ACHHUZ6+06QPRm88+splJL95nkZ5PtLUwDV4iXmeeiBGsIrwFJKBtIy5ZP/Ld+fVpUUXNV95BTsR4A== X-Received: by 2002:a17:907:62a0:b0:958:46aa:7f98 with SMTP id nd32-20020a17090762a000b0095846aa7f98mr396315ejc.48.1683241912433; Thu, 04 May 2023 16:11:52 -0700 (PDT) Content-Type: multipart/alternative; boundary="------------Um51gNivd52xl3sxe2jlKl5o" Message-ID: <0fec9791-405a-1c6f-9f74-cf2026a2039b@gmail.com> Date: Fri, 5 May 2023 01:11:50 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 To: musl@lists.openwall.com, enh , =?UTF-8?B?SuKCkeKCmeKCmyBHdXN0ZWR0?= Cc: =?UTF-8?B?572X5YuH5YiaKFlvbmdnYW5nIEx1byk=?= , Jason Ekstrand References: <20220923162518.56284329@inria.fr> <20221119153350.292e390b@inria.fr> <20230504081942.065fc12f@inria.fr> Content-Language: en-US From: Gabriel Ravier In-Reply-To: Subject: Re: [musl] C23 implications for C libraries This is a multi-part message in MIME format. --------------Um51gNivd52xl3sxe2jlKl5o Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 5/4/23 18:03, enh wrote: > > > On Wed, May 3, 2023 at 11:19 PM 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. > > > 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. musl aims to have binary compatibility with glibc, so it very much matters in this case > 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ₑₙₛ > > -- > :: ICube :::::::::::::::::::::::::::::: deputy director :: > :: Université de Strasbourg :::::::::::::::::::::: ICPS :: > :: INRIA Nancy Grand Est :::::::::::::::::::::::: Camus :: > :: :::::::::::::::::::::::::::::::::::: ☎ +33 368854536 > :: > :: https://icube-icps.unistra.fr/index.php/Jens_Gustedt :: > --------------Um51gNivd52xl3sxe2jlKl5o Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 5/4/23 18:03, enh wrote:


On Wed, May 3, 2023 at 11:19 PM Jₑₙₛ 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 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?

 
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.

musl aims to have binary compatibility with glibc, so it very much matters in this case

 
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ₑₙₛ

--
:: ICube :::::::::::::::::::::::::::::: deputy director ::
:: Université de Strasbourg :::::::::::::::::::::: ICPS ::
:: INRIA Nancy Grand Est :::::::::::::::::::::::: Camus ::
:: :::::::::::::::::::::::::::::::::::: ☎ +33 368854536 ::
:: https://icube-icps.unistra.fr/index.php/Jens_Gustedt ::


--------------Um51gNivd52xl3sxe2jlKl5o--