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=-1.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_MSPIKE_H2,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 15402 invoked from network); 4 May 2023 16:03:20 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 4 May 2023 16:03:20 -0000 Received: (qmail 27876 invoked by uid 550); 4 May 2023 16:03:17 -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 27842 invoked from network); 4 May 2023 16:03:16 -0000 Date: Thu, 4 May 2023 12:03:04 -0400 From: Rich Felker To: =?utf-8?B?SuKCkeKCmeKCmw==?= Gustedt Cc: enh , musl@lists.openwall.com, =?utf-8?B?572X5YuH5YiaKFlvbmdnYW5nIEx1byk=?= , Jason Ekstrand Message-ID: <20230504160304.GC4163@brightrain.aerifal.cx> References: <20220923162518.56284329@inria.fr> <20221119153350.292e390b@inria.fr> <20230504081942.065fc12f@inria.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20230504081942.065fc12f@inria.fr> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] C23 implications for C libraries 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. But I'm open to discussion. Rich