* [musl] C23 implications for C libraries @ 2022-09-23 14:25 Jₑₙₛ Gustedt 2022-09-23 14:58 ` Rich Felker ` (3 more replies) 0 siblings, 4 replies; 40+ messages in thread From: Jₑₙₛ Gustedt @ 2022-09-23 14:25 UTC (permalink / raw) To: musl [-- Attachment #1: Type: text/plain, Size: 643 bytes --] Hello, I have started to compile a document that tries to collect everything a C library needs for C23 compliance: https://htmlpreview.github.io/?https://icube-forge.unistra.fr/icps/c23-library/-/raw/main/README.html This is by far not complete and I will try to fill the holes in the next weeks. Let me know if you have any particular questions/remarks/additions. Thanks Jₑₙₛ -- :: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS ::: :: :::::::::::::::::::::: gsm France : +33 651400183 :: :: ::::::::::::::: gsm international : +49 15737185122 :: :: http://icube-icps.unistra.fr/index.php/Jens_Gustedt :: [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 195 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [musl] C23 implications for C libraries 2022-09-23 14:25 [musl] C23 implications for C libraries Jₑₙₛ Gustedt @ 2022-09-23 14:58 ` Rich Felker 2022-09-23 15:11 ` Alexander Monakov 2022-09-23 15:35 ` Jₑₙₛ Gustedt 2022-09-23 15:28 ` enh ` (2 subsequent siblings) 3 siblings, 2 replies; 40+ messages in thread From: Rich Felker @ 2022-09-23 14:58 UTC (permalink / raw) To: Jₑₙₛ Gustedt; +Cc: musl On Fri, Sep 23, 2022 at 04:25:18PM +0200, Jₑₙₛ Gustedt wrote: > Hello, > I have started to compile a document that tries to collect everything > a C library needs for C23 compliance: > > https://htmlpreview.github.io/?https://icube-forge.unistra.fr/icps/c23-library/-/raw/main/README.html > > This is by far not complete and I will try to fill the holes in the > next weeks. Let me know if you have any particular > questions/remarks/additions. Thanks for putting this together. For the most part these look tractable. One small note on wording: your usage of FTM differs from the one we're used to and that's in POSIX, where FTMs are macros the application defines to request some functionality or compliance profile from the implementation, not macros the implementation uses to advertise features to the application. One cute observation: now that headers define macros for their versions, can we just replace the multiple-inclusion test macros with these? I think so. Rich ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [musl] C23 implications for C libraries 2022-09-23 14:58 ` Rich Felker @ 2022-09-23 15:11 ` Alexander Monakov 2022-09-23 15:35 ` Jₑₙₛ Gustedt 1 sibling, 0 replies; 40+ messages in thread From: Alexander Monakov @ 2022-09-23 15:11 UTC (permalink / raw) To: musl; +Cc: Jₑₙₛ Gustedt On Fri, 23 Sep 2022, Rich Felker wrote: > One small note on wording: your usage of FTM differs from the one > we're used to and that's in POSIX, where FTMs are macros the > application defines to request some functionality or compliance ^^^^^^^ > profile from the implementation, not macros the implementation uses to > advertise features to the application. Sure would be nicer to users if those were called "feature request macros" instead. Alexander ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [musl] C23 implications for C libraries 2022-09-23 14:58 ` Rich Felker 2022-09-23 15:11 ` Alexander Monakov @ 2022-09-23 15:35 ` Jₑₙₛ Gustedt 1 sibling, 0 replies; 40+ messages in thread From: Jₑₙₛ Gustedt @ 2022-09-23 15:35 UTC (permalink / raw) To: Rich Felker; +Cc: musl [-- Attachment #1: Type: text/plain, Size: 1607 bytes --] Rich, on Fri, 23 Sep 2022 10:58:44 -0400 you (Rich Felker <dalias@libc.org>) wrote: > On Fri, Sep 23, 2022 at 04:25:18PM +0200, Jₑₙₛ Gustedt wrote: > > Hello, > > I have started to compile a document that tries to collect > > everything a C library needs for C23 compliance: > > > > https://htmlpreview.github.io/?https://icube-forge.unistra.fr/icps/c23-library/-/raw/main/README.html > > > > This is by far not complete and I will try to fill the holes in the > > next weeks. Let me know if you have any particular > > questions/remarks/additions. > > Thanks for putting this together. For the most part these look > tractable. > > One small note on wording: your usage of FTM differs from the one > we're used to and that's in POSIX, where FTMs are macros the > application defines to request some functionality or compliance > profile from the implementation, not macros the implementation uses to > advertise features to the application. Sorry for that, the C standard calls these "Conditional feature macros" > One cute observation: now that headers define macros for their > versions, can we just replace the multiple-inclusion test macros with > these? I think so. Yes, indeed, I don't think that there is much that speaks against using them also in that way. Jₑₙₛ -- :: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS ::: :: :::::::::::::::::::::: gsm France : +33 651400183 :: :: ::::::::::::::: gsm international : +49 15737185122 :: :: http://icube-icps.unistra.fr/index.php/Jens_Gustedt :: [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 195 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [musl] C23 implications for C libraries 2022-09-23 14:25 [musl] C23 implications for C libraries Jₑₙₛ Gustedt 2022-09-23 14:58 ` Rich Felker @ 2022-09-23 15:28 ` enh 2022-09-23 15:40 ` Jₑₙₛ Gustedt 2022-11-18 20:46 ` 罗勇刚(Yonggang Luo) 2022-11-21 11:46 ` Reini Urban 3 siblings, 1 reply; 40+ messages in thread From: enh @ 2022-09-23 15:28 UTC (permalink / raw) To: musl [-- Attachment #1: Type: text/plain, Size: 1127 bytes --] since you asked for comments, it would have been even better to have direct links to the relevant documents (such as https://www.open-std.org/jtc1/sc22/WG14/www/docs/n2829.htm for the assert() changes), but just having a list of things to search out is useful in its own right, so thanks for this! On Fri, Sep 23, 2022 at 7:25 AM Jₑₙₛ Gustedt <jens.gustedt@inria.fr> wrote: > Hello, > I have started to compile a document that tries to collect everything > a C library needs for C23 compliance: > > > https://htmlpreview.github.io/?https://icube-forge.unistra.fr/icps/c23-library/-/raw/main/README.html > > This is by far not complete and I will try to fill the holes in the > next weeks. Let me know if you have any particular > questions/remarks/additions. > > Thanks > Jₑₙₛ > > -- > :: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS ::: > :: :::::::::::::::::::::: gsm France : +33 651400183 > <+33%206%2051%2040%2001%2083> :: > :: ::::::::::::::: gsm international : +49 15737185122 > <+49%201573%207185122> :: > :: http://icube-icps.unistra.fr/index.php/Jens_Gustedt :: > [-- Attachment #2: Type: text/html, Size: 1878 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [musl] C23 implications for C libraries 2022-09-23 15:28 ` enh @ 2022-09-23 15:40 ` Jₑₙₛ Gustedt 2022-09-23 23:52 ` enh 0 siblings, 1 reply; 40+ messages in thread From: Jₑₙₛ Gustedt @ 2022-09-23 15:40 UTC (permalink / raw) To: enh; +Cc: musl [-- Attachment #1: Type: text/plain, Size: 949 bytes --] enh, on Fri, 23 Sep 2022 08:28:52 -0700 you (enh <enh@google.com>) wrote: > since you asked for comments, it would have been even better to have > direct links to the relevant documents (such as > https://www.open-std.org/jtc1/sc22/WG14/www/docs/n2829.htm for the > assert() changes), yes, the idea is to add such a link when I manage to discuss the particular feature more in detail my hope is also still that we may have a diff-version of the C standard at some point in the nearer future, but it seems that the editors have problems with the tooling for that > but just having a list of things to search out is > useful in its own right, so thanks for this! Thanks Jₑₙₛ -- :: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS ::: :: :::::::::::::::::::::: gsm France : +33 651400183 :: :: ::::::::::::::: gsm international : +49 15737185122 :: :: http://icube-icps.unistra.fr/index.php/Jens_Gustedt :: [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 195 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [musl] C23 implications for C libraries 2022-09-23 15:40 ` Jₑₙₛ Gustedt @ 2022-09-23 23:52 ` enh 2022-09-24 7:31 ` Jₑₙₛ Gustedt 0 siblings, 1 reply; 40+ messages in thread From: enh @ 2022-09-23 23:52 UTC (permalink / raw) To: Jₑₙₛ Gustedt; +Cc: musl [-- Attachment #1: Type: text/plain, Size: 1500 bytes --] On Fri, Sep 23, 2022 at 8:40 AM Jₑₙₛ Gustedt <jens.gustedt@inria.fr> wrote: > enh, > > on Fri, 23 Sep 2022 08:28:52 -0700 you (enh <enh@google.com>) wrote: > > > since you asked for comments, it would have been even better to have > > direct links to the relevant documents (such as > > https://www.open-std.org/jtc1/sc22/WG14/www/docs/n2829.htm for the > > assert() changes), > > yes, the idea is to add such a link when I manage to discuss the > particular feature more in detail > that... > my hope is also still that we may have a diff-version of the C standard > at some point in the nearer future, but it seems that the editors have > problems with the tooling for that > ...and that sound even better, yes --- but i always worry about "the perfect is the enemy of the good". a 20% solution today is worth more to me than a 100% solution a year from now :-) anyone know whether <stdbit.h> is likely to be implemented by gcc/clang (since most/all of that stuff should end up as __builtin_foo() anyway)? > > but just having a list of things to search out is > > useful in its own right, so thanks for this! > > Thanks > Jₑₙₛ > > -- > :: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS ::: > :: :::::::::::::::::::::: gsm France : +33 651400183 > <+33%206%2051%2040%2001%2083> :: > :: ::::::::::::::: gsm international : +49 15737185122 > <+49%201573%207185122> :: > :: http://icube-icps.unistra.fr/index.php/Jens_Gustedt :: > [-- Attachment #2: Type: text/html, Size: 2603 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [musl] C23 implications for C libraries 2022-09-23 23:52 ` enh @ 2022-09-24 7:31 ` Jₑₙₛ Gustedt 2022-09-26 3:18 ` Damian McGuckin ` (3 more replies) 0 siblings, 4 replies; 40+ messages in thread From: Jₑₙₛ Gustedt @ 2022-09-24 7:31 UTC (permalink / raw) To: enh; +Cc: musl [-- Attachment #1: Type: text/plain, Size: 1860 bytes --] enh, on Fri, 23 Sep 2022 16:52:53 -0700 you (enh <enh@google.com>) wrote: > On Fri, Sep 23, 2022 at 8:40 AM Jₑₙₛ Gustedt <jens.gustedt@inria.fr> > wrote: > > > enh, > > > > on Fri, 23 Sep 2022 08:28:52 -0700 you (enh <enh@google.com>) wrote: > > > > > since you asked for comments, it would have been even better to > > > have direct links to the relevant documents (such as > > > https://www.open-std.org/jtc1/sc22/WG14/www/docs/n2829.htm for the > > > assert() changes), > > > > yes, the idea is to add such a link when I manage to discuss the > > particular feature more in detail > > > > that... wow, that's pushy > > my hope is also still that we may have a diff-version of the C > > standard at some point in the nearer future, but it seems that the > > editors have problems with the tooling for that > > > > ...and that sound even better, yes --- but i always worry about "the > perfect is the enemy of the good". a 20% solution today is worth more > to me than a 100% solution a year from now :-) Much as musl, the C standard is a volunteer project. Instead of reclaiming things you should ask yourself how can you or your company help. As all volunteer work, this is best effort. WG14 would have a much better stand if more of the industry would inject real work force into the committee. Currently there seem only be two of the bigger players that have people there that substantially work on the C standard during their office hours. The others are mostly academics like myself and people working in their free time. Thanks Jₑₙₛ -- :: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS ::: :: :::::::::::::::::::::: gsm France : +33 651400183 :: :: ::::::::::::::: gsm international : +49 15737185122 :: :: http://icube-icps.unistra.fr/index.php/Jens_Gustedt :: [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 195 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [musl] C23 implications for C libraries 2022-09-24 7:31 ` Jₑₙₛ Gustedt @ 2022-09-26 3:18 ` Damian McGuckin 2022-09-26 3:33 ` Rich Felker ` (2 subsequent siblings) 3 siblings, 0 replies; 40+ messages in thread From: Damian McGuckin @ 2022-09-26 3:18 UTC (permalink / raw) To: musl; +Cc: enh On Sat, 24 Sep 2022, J??? Gustedt wrote: > As all volunteer work, this is best effort. WG14 would have a much > better stand if more of the industry would inject real work force into > the committee. Currently there seem only be two of the bigger players > that have people there that substantially work on the C standard during > their office hours. The others are mostly academics like myself and > people working in their free time. And some of us are from companies which are tiny compared to the big guys. Here too, it is still largely volumteer work which we do in our free time, well ... outside normal working hours anyway! Stay safe - Damian Pacific Engineering Systems International, 277-279 Broadway, Glebe NSW 2037 Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here Views & opinions here are mine and not those of any past or present employer ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [musl] C23 implications for C libraries 2022-09-24 7:31 ` Jₑₙₛ Gustedt 2022-09-26 3:18 ` Damian McGuckin @ 2022-09-26 3:33 ` Rich Felker 2022-09-26 10:49 ` Florian Weimer 2022-09-26 20:13 ` enh 3 siblings, 0 replies; 40+ messages in thread From: Rich Felker @ 2022-09-26 3:33 UTC (permalink / raw) To: Jₑₙₛ Gustedt; +Cc: enh, musl On Sat, Sep 24, 2022 at 09:31:06AM +0200, Jₑₙₛ Gustedt wrote: > enh, > > on Fri, 23 Sep 2022 16:52:53 -0700 you (enh <enh@google.com>) wrote: > > > On Fri, Sep 23, 2022 at 8:40 AM Jₑₙₛ Gustedt <jens.gustedt@inria.fr> > > wrote: > > > > > enh, > > > > > > on Fri, 23 Sep 2022 08:28:52 -0700 you (enh <enh@google.com>) wrote: > > > > > > > since you asked for comments, it would have been even better to > > > > have direct links to the relevant documents (such as > > > > https://www.open-std.org/jtc1/sc22/WG14/www/docs/n2829.htm for the > > > > assert() changes), > > > > > > yes, the idea is to add such a link when I manage to discuss the > > > particular feature more in detail > > > > > > > that... > > wow, that's pushy > > > > my hope is also still that we may have a diff-version of the C > > > standard at some point in the nearer future, but it seems that the > > > editors have problems with the tooling for that > > > > > > > ...and that sound even better, yes --- but i always worry about "the > > perfect is the enemy of the good". a 20% solution today is worth more > > to me than a 100% solution a year from now :-) > > Much as musl, the C standard is a volunteer project. Instead of > reclaiming things you should ask yourself how can you or your company > help. > > As all volunteer work, this is best effort. WG14 would have a much > better stand if more of the industry would inject real work force into > the committee. Currently there seem only be two of the bigger players > that have people there that substantially work on the C standard > during their office hours. The others are mostly academics like myself > and people working in their free time. All that ^^^ ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [musl] C23 implications for C libraries 2022-09-24 7:31 ` Jₑₙₛ Gustedt 2022-09-26 3:18 ` Damian McGuckin 2022-09-26 3:33 ` Rich Felker @ 2022-09-26 10:49 ` Florian Weimer 2022-09-26 12:52 ` Jₑₙₛ Gustedt 2022-09-26 20:13 ` enh 3 siblings, 1 reply; 40+ messages in thread From: Florian Weimer @ 2022-09-26 10:49 UTC (permalink / raw) To: Jₑₙₛ Gustedt; +Cc: enh, musl * J. ₑₙₛ Gustedt: > Much as musl, the C standard is a volunteer project. Instead of > reclaiming things you should ask yourself how can you or your company > help. > > As all volunteer work, this is best effort. WG14 would have a much > better stand if more of the industry would inject real work force into > the committee. Currently there seem only be two of the bigger players > that have people there that substantially work on the C standard > during their office hours. The others are mostly academics like myself > and people working in their free time. The official contribution policies are here: C - Contributing <https://www.open-std.org/jtc1/sc22/wg14/www/contributing.html> Note that it never says where to submit your contribution. Actually, towards the end, that document explains why: participation from “all members of the broader C community” is pretty much rejected: | While we wish we could encourage all members of the broader C | community to participate in the standardization process, we are an | ISO working group and subject to their requirements. Contributors | who are making sustained contributions should join their local | national body to officially become a WG14 expert. For more | information on joining a National Body, please see ISO | <https://www.iso.org/members.html>. Joining a “National Body” requires a non-nominal yearly fee, depending on where you live, and even then the relevant committee or group there needs to appoint you to WG14 (which may require participation in additonal, regular meetings). I'm sure there are ways around that if you know the right people, but I expect the issues around representation you observe are directly related to these admission policies. This situation is not going to change any time soon, and that's one reason why I started the libc-coord mailing list. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [musl] C23 implications for C libraries 2022-09-26 10:49 ` Florian Weimer @ 2022-09-26 12:52 ` Jₑₙₛ Gustedt 0 siblings, 0 replies; 40+ messages in thread From: Jₑₙₛ Gustedt @ 2022-09-26 12:52 UTC (permalink / raw) To: Florian Weimer; +Cc: enh, musl [-- Attachment #1: Type: text/plain, Size: 2045 bytes --] Florian, you are turning what I wanted to say upside down. I was explicitly targeting the participation of the "big players". on Mon, 26 Sep 2022 12:49:26 +0200 you (Florian Weimer <fw@deneb.enyo.de>) wrote: > Joining a “National Body” requires a non-nominal yearly fee, depending > on where you live, and even then the relevant committee or group there > needs to appoint you to WG14 (which may require participation in > additonal, regular meetings). I'm sure there are ways around that if > you know the right people, but I expect the issues around > representation you observe are directly related to these admission > policies. The big players generally already participate in national bodies and by that have no difficulty at all to send personal and real work force into whatever ISO committee they like. Not to participate in WG14 is an informed choice by most of them. We had some participation by some of them in the past. These people quickly disappeared when it was clear that this was not just lobbying and name dropping, but that in the contrary competence, persistence, real engagement and substantial work is required to have an influence. You are right though, that for small enterprises participation might be difficult. All the more it is interesting to note that a large fraction of WG14 comes exactly from such contexts. So yes, the ISO system is less than ideal, and I have not much of an answer on how to improve that situation. What I tried to emphasize upon is that we would be in a better shape if important parts of the industry would take up their responsibility. There are multiple ways to do so, be it by sending in their own people, subsidizing those that are already there, providing grants, whatever. Thanks Jₑₙₛ -- :: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS ::: :: :::::::::::::::::::::: gsm France : +33 651400183 :: :: ::::::::::::::: gsm international : +49 15737185122 :: :: http://icube-icps.unistra.fr/index.php/Jens_Gustedt :: [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 195 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [musl] C23 implications for C libraries 2022-09-24 7:31 ` Jₑₙₛ Gustedt ` (2 preceding siblings ...) 2022-09-26 10:49 ` Florian Weimer @ 2022-09-26 20:13 ` enh 3 siblings, 0 replies; 40+ messages in thread From: enh @ 2022-09-26 20:13 UTC (permalink / raw) To: Jₑₙₛ Gustedt; +Cc: musl [-- Attachment #1: Type: text/plain, Size: 2959 bytes --] On Sat, Sep 24, 2022 at 12:31 AM Jₑₙₛ Gustedt <jens.gustedt@inria.fr> wrote: > enh, > > on Fri, 23 Sep 2022 16:52:53 -0700 you (enh <enh@google.com>) wrote: > > > On Fri, Sep 23, 2022 at 8:40 AM Jₑₙₛ Gustedt <jens.gustedt@inria.fr> > > wrote: > > > > > enh, > > > > > > on Fri, 23 Sep 2022 08:28:52 -0700 you (enh <enh@google.com>) wrote: > > > > > > > since you asked for comments, it would have been even better to > > > > have direct links to the relevant documents (such as > > > > https://www.open-std.org/jtc1/sc22/WG14/www/docs/n2829.htm for the > > > > assert() changes), > > > > > > yes, the idea is to add such a link when I manage to discuss the > > > particular feature more in detail > > > > > > > that... > > wow, that's pushy > apologies if it came across that way, but it was actually meant in the opposite sense... > > > my hope is also still that we may have a diff-version of the C > > > standard at some point in the nearer future, but it seems that the > > > editors have problems with the tooling for that > > > > > > > ...and that sound even better, yes --- but i always worry about "the > > perfect is the enemy of the good". a 20% solution today is worth more > > to me than a 100% solution a year from now :-) > > Much as musl, the C standard is a volunteer project. Instead of > reclaiming things you should ask yourself how can you or your company > help. > > As all volunteer work, this is best effort. WG14 would have a much > better stand if more of the industry would inject real work force into > the committee. Currently there seem only be two of the bigger players > that have people there that substantially work on the C standard > during their office hours. The others are mostly academics like myself > and people working in their free time. > ...specifically: given that we're _all_ just doing this in "spare" time because new c language/library features aren't a priority for anyone i know[1], i think it's _especially_ important to avoid the perfect being the enemy of the good ... a wiki somewhere that we can all edit now, say, is better than a great doc that isn't ready _because_ we can all help. (i'd have added the Nxxxx links for the ones i looked up as i was reading your summary, for example.) (since i see he's on this thread, credit to florian weimer's co-ordination list --- that stands out as probably the most useful thing we have in the implementor community right now.) ____ 1. unlike things that make a significant difference to safety/correctness, such as "move to rust". Thanks > Jₑₙₛ > > -- > :: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS ::: > :: :::::::::::::::::::::: gsm France : +33 651400183 > <+33%206%2051%2040%2001%2083> :: > :: ::::::::::::::: gsm international : +49 15737185122 > <+49%201573%207185122> :: > :: http://icube-icps.unistra.fr/index.php/Jens_Gustedt :: > [-- Attachment #2: Type: text/html, Size: 4457 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [musl] C23 implications for C libraries 2022-09-23 14:25 [musl] C23 implications for C libraries Jₑₙₛ Gustedt 2022-09-23 14:58 ` Rich Felker 2022-09-23 15:28 ` enh @ 2022-11-18 20:46 ` 罗勇刚(Yonggang Luo) 2022-11-19 14:33 ` Jₑₙₛ Gustedt 2022-11-19 18:31 ` Rich Felker 2022-11-21 11:46 ` Reini Urban 3 siblings, 2 replies; 40+ messages in thread From: 罗勇刚(Yonggang Luo) @ 2022-11-18 20:46 UTC (permalink / raw) To: musl, Jens Gustedt, Jason Ekstrand [-- Attachment #1: Type: text/plain, Size: 1412 bytes --] There is a concept called CLOCK_MONOTONIC_RAW (since Linux 2.6.28; Linux-specific), May C2x provide TIME_MONOTONIC_RAW in future or can we just implement TIME_MONOTONIC with CLOCK_MONOTONIC_RAW on Linux? When implement mesa vulkan driver, it's ask for CLOCK_MONOTONIC_RAW at https://gitlab.freedesktop.org/mesa/mesa/-/blob/c6c5949ff70a47c47795fe9161a7514173b5be24/src/vulkan/runtime/vk_device.c#L557 May intention is using C2x timespec_get to replace function vk_clock_gettime but it's lack of TIME_MONOTONIC_RAW, so I don't know what's the best way On Fri, Sep 23, 2022 at 10:25 PM Jₑₙₛ Gustedt <jens.gustedt@inria.fr> wrote: > > Hello, > I have started to compile a document that tries to collect everything > a C library needs for C23 compliance: > > https://htmlpreview.github.io/?https://icube-forge.unistra.fr/icps/c23-library/-/raw/main/README.html > > This is by far not complete and I will try to fill the holes in the > next weeks. Let me know if you have any particular > questions/remarks/additions. > > Thanks > Jₑₙₛ > > -- > :: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS ::: > :: :::::::::::::::::::::: gsm France : +33 651400183 :: > :: ::::::::::::::: gsm international : +49 15737185122 :: > :: http://icube-icps.unistra.fr/index.php/Jens_Gustedt :: -- 此致 礼 罗勇刚 Yours sincerely, Yonggang Luo [-- Attachment #2: Type: text/html, Size: 1968 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [musl] C23 implications for C libraries 2022-11-18 20:46 ` 罗勇刚(Yonggang Luo) @ 2022-11-19 14:33 ` Jₑₙₛ Gustedt 2022-11-19 17:19 ` 罗勇刚(Yonggang Luo) ` (2 more replies) 2022-11-19 18:31 ` Rich Felker 1 sibling, 3 replies; 40+ messages in thread From: Jₑₙₛ Gustedt @ 2022-11-19 14:33 UTC (permalink / raw) To: 罗勇刚(Yonggang Luo); +Cc: musl, Jason Ekstrand [-- Attachment #1: Type: text/plain, Size: 3661 bytes --] 罗勇刚, on Sat, 19 Nov 2022 04:46:22 +0800 you (罗勇刚(Yonggang Luo) <luoyonggang@gmail.com>) wrote: > There is a concept called CLOCK_MONOTONIC_RAW (since Linux 2.6.28; > Linux-specific), > May C2x provide TIME_MONOTONIC_RAW in future or can we just implement > TIME_MONOTONIC with > CLOCK_MONOTONIC_RAW on Linux? I am not completely sure what you are asking. C2x was the short name for C23 when we did not yet know that it will come out in 2023. C23 indeed adds three *optional* time bases `TIME_MONOTONIC`, `TIME_ACTIVE` and `TIME_THREAD_ACTIVE` which are modeled after the POSIX clocks `CLOCK_MONOTONIC`, `CLOCK_PROCESS_CPUTIME_ID` and `CLOCK_THREAD_CPUTIME_ID`, respectively. Using them to map to other POSIX clocks, even if these are conceptually close, is not a good idea, I think. That said, having time bases for C other than `TIME_UTC` is at the liberty of the implementation, so musl could easily provide the equivalent to all POSIX clocks that it interfaces. Currently these are #define CLOCK_REALTIME 0 #define CLOCK_MONOTONIC 1 #define CLOCK_PROCESS_CPUTIME_ID 2 #define CLOCK_THREAD_CPUTIME_ID 3 #define CLOCK_MONOTONIC_RAW 4 #define CLOCK_REALTIME_COARSE 5 #define CLOCK_MONOTONIC_COARSE 6 #define CLOCK_BOOTTIME 7 #define CLOCK_REALTIME_ALARM 8 #define CLOCK_BOOTTIME_ALARM 9 #define CLOCK_SGI_CYCLE 10 #define CLOCK_TAI 11 This could easily be done by using #define TIME_UTC (CLOCK_REALTIME+1) #define TIME_MONOTONIC (CLOCK_MONOTONIC+1) #define TIME_ATIVE (CLOCK_PROCESS_CPUTIME_I+1) #define TIME_THREAD_ACTIVE (CLOCK_THREAD_CPUTIME_ID+1) #define TIME_MONOTONIC_RAW (CLOCK_MONOTONIC_RAW+1) #define TIME_UTC_COARSE (CLOCK_REALTIME_COARSE+1) #define TIME_MONOTONIC_COARSE (CLOCK_MONOTONIC_COARSE+1) #define TIME_BOOTTIME (CLOCK_BOOTTIME+1) #define TIME_UTC_ALARM (CLOCK_REALTIME_ALARM+1) #define TIME_BOOTTIME_ALARM (CLOCK_BOOTTIME_ALARM+1) #define TIME_SGI_CYCLE (CLOCK_SGI_CYCLE+1) #define TIME_TAI (CLOCK_TAI+1) and then adapting `timespec_get` a bit. This would be conforming to current and future C, because the `TIME_` prefix is already reserved for that purpose. Unfortunately the choice of the values is an ABI choice, so before doing so we should be sure that other C libraries on Linux use the same values. (Rich: would you accept a patch that goes in that direction?) > When implement mesa vulkan driver, > it's ask for CLOCK_MONOTONIC_RAW at > > https://gitlab.freedesktop.org/mesa/mesa/-/blob/c6c5949ff70a47c47795fe9161a7514173b5be24/src/vulkan/runtime/vk_device.c#L557 > > May intention is using C2x timespec_get > to replace function > vk_clock_gettime but it's lack of TIME_MONOTONIC_RAW, so I don't know > what's the best way I am not sure why you'd want to do this, are you trying to port that code such that it gets rid of any reference to POSIX interfaces? If so, you'd have to wait and see if other C libraries will interface the "new" time bases that C23 specifies. (Or does your code only run with musl or windows?) Then to know if a fallback to `CLOCK_MONOTONIC_RAW` is sensible, you would have to inspect for which clocks the current function is really used and if fallback is even needed in real life. Jₑₙₛ -- :: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS ::: :: :::::::::::::::::::::: gsm France : +33 651400183 :: :: ::::::::::::::: gsm international : +49 15737185122 :: :: http://icube-icps.unistra.fr/index.php/Jens_Gustedt :: [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 195 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [musl] C23 implications for C libraries 2022-11-19 14:33 ` Jₑₙₛ Gustedt @ 2022-11-19 17:19 ` 罗勇刚(Yonggang Luo) 2022-11-20 8:23 ` Jₑₙₛ Gustedt 2022-11-19 18:28 ` Rich Felker 2023-05-03 22:58 ` enh 2 siblings, 1 reply; 40+ messages in thread From: 罗勇刚(Yonggang Luo) @ 2022-11-19 17:19 UTC (permalink / raw) To: Jₑₙₛ Gustedt; +Cc: musl, Jason Ekstrand [-- Attachment #1: Type: text/plain, Size: 4630 bytes --] On Sat, Nov 19, 2022 at 10:33 PM Jₑₙₛ Gustedt <jens.gustedt@inria.fr> wrote: > > 罗勇刚, > > on Sat, 19 Nov 2022 04:46:22 +0800 you (罗勇刚(Yonggang Luo) > <luoyonggang@gmail.com>) wrote: > > > There is a concept called CLOCK_MONOTONIC_RAW (since Linux 2.6.28; > > Linux-specific), > > May C2x provide TIME_MONOTONIC_RAW in future or can we just implement > > TIME_MONOTONIC with > > CLOCK_MONOTONIC_RAW on Linux? > > I am not completely sure what you are asking. C2x was the short name > for C23 when we did not yet know that it will come out in 2023. > > C23 indeed adds three *optional* time bases `TIME_MONOTONIC`, > `TIME_ACTIVE` and `TIME_THREAD_ACTIVE` which are modeled after the > POSIX clocks `CLOCK_MONOTONIC`, `CLOCK_PROCESS_CPUTIME_ID` and > `CLOCK_THREAD_CPUTIME_ID`, respectively. Using them to map to other > POSIX clocks, even if these are conceptually close, is not a good > idea, I think. > > That said, having time bases for C other than `TIME_UTC` is at the > liberty of the implementation, so musl could easily provide the > equivalent to all POSIX clocks that it interfaces. Currently these are > > #define CLOCK_REALTIME 0 > #define CLOCK_MONOTONIC 1 > #define CLOCK_PROCESS_CPUTIME_ID 2 > #define CLOCK_THREAD_CPUTIME_ID 3 > #define CLOCK_MONOTONIC_RAW 4 > #define CLOCK_REALTIME_COARSE 5 > #define CLOCK_MONOTONIC_COARSE 6 > #define CLOCK_BOOTTIME 7 > #define CLOCK_REALTIME_ALARM 8 > #define CLOCK_BOOTTIME_ALARM 9 > #define CLOCK_SGI_CYCLE 10 > #define CLOCK_TAI 11 > > This could easily be done by using > > #define TIME_UTC (CLOCK_REALTIME+1) > #define TIME_MONOTONIC (CLOCK_MONOTONIC+1) > #define TIME_ATIVE (CLOCK_PROCESS_CPUTIME_I+1) > #define TIME_THREAD_ACTIVE (CLOCK_THREAD_CPUTIME_ID+1) > #define TIME_MONOTONIC_RAW (CLOCK_MONOTONIC_RAW+1) > #define TIME_UTC_COARSE (CLOCK_REALTIME_COARSE+1) > #define TIME_MONOTONIC_COARSE (CLOCK_MONOTONIC_COARSE+1) > #define TIME_BOOTTIME (CLOCK_BOOTTIME+1) > #define TIME_UTC_ALARM (CLOCK_REALTIME_ALARM+1) > #define TIME_BOOTTIME_ALARM (CLOCK_BOOTTIME_ALARM+1) > #define TIME_SGI_CYCLE (CLOCK_SGI_CYCLE+1) > #define TIME_TAI (CLOCK_TAI+1) I like this list, as It doesn't have to be implemented, have such a complete list in C2x standard is very good > > and then adapting `timespec_get` a bit. This would be conforming to > current and future C, because the `TIME_` prefix is already reserved > for that purpose. > > Unfortunately the choice of the values is an ABI choice, so before > doing so we should be sure that other C libraries on Linux use the > same values. > > (Rich: would you accept a patch that goes in that direction?) > > > When implement mesa vulkan driver, > > it's ask for CLOCK_MONOTONIC_RAW at > > > > https://gitlab.freedesktop.org/mesa/mesa/-/blob/c6c5949ff70a47c47795fe9161a7514173b5be24/src/vulkan/runtime/vk_device.c#L557 > > > > May intention is using C2x timespec_get > > to replace function > > vk_clock_gettime but it's lack of TIME_MONOTONIC_RAW, so I don't know > > what's the best way > > I am not sure why you'd want to do this, are you trying to port that > code such that it gets rid of any reference to POSIX interfaces? If > so, you'd have to wait and see if other C libraries will interface the > "new" time bases that C23 specifies. (Or does your code only run with > musl or windows?) Yeap, I want to gets rid of any reference to POSIX interfaces, as I am writing code shared between windows and linux or even more platforms(with or without posix support), And I am implementing timespec_get in mesa code base to avoid waiting c23 or future c2x to be implemented by c standard library provider, currently for mesa's special usage, We need access to CLOCK_REALTIME CLOCK_MONOTONIC and CLOCK_MONOTONIC_RAW, so the equivalent TIME_UTC, TIME_MONOTONIC, TIME_MONOTONIC_RAW in Cx standard is good. > > Then to know if a fallback to `CLOCK_MONOTONIC_RAW` is sensible, you > would have to inspect for which clocks the current function is really > used and if fallback is even needed in real life. > > Jₑₙₛ > > -- > :: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS ::: > :: :::::::::::::::::::::: gsm France : +33 651400183 :: > :: ::::::::::::::: gsm international : +49 15737185122 :: > :: http://icube-icps.unistra.fr/index.php/Jens_Gustedt :: -- 此致 礼 罗勇刚 Yours sincerely, Yonggang Luo [-- Attachment #2: Type: text/html, Size: 5626 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [musl] C23 implications for C libraries 2022-11-19 17:19 ` 罗勇刚(Yonggang Luo) @ 2022-11-20 8:23 ` Jₑₙₛ Gustedt 0 siblings, 0 replies; 40+ messages in thread From: Jₑₙₛ Gustedt @ 2022-11-20 8:23 UTC (permalink / raw) To: 罗勇刚(Yonggang Luo); +Cc: musl, Jason Ekstrand [-- Attachment #1: Type: text/plain, Size: 2154 bytes --] 罗勇刚, on Sun, 20 Nov 2022 01:19:40 +0800 you (罗勇刚(Yonggang Luo) <luoyonggang@gmail.com>) wrote: > > I am not sure why you'd want to do this, are you trying to port that > > code such that it gets rid of any reference to POSIX interfaces? If > > so, you'd have to wait and see if other C libraries will interface > > the "new" time bases that C23 specifies. (Or does your code only > > run with musl or windows?) > > Yeap, I want to gets rid of any reference to POSIX interfaces, as I am > writing code shared between windows and linux or even more > platforms(with or without posix support), And I am implementing > timespec_get in mesa code base to avoid waiting c23 or future c2x to > be implemented by c standard library provider, currently for mesa's > special usage, We need access to CLOCK_REALTIME CLOCK_MONOTONIC and > CLOCK_MONOTONIC_RAW, so the equivalent TIME_UTC, TIME_MONOTONIC, > TIME_MONOTONIC_RAW in Cx standard is good. There is not much chance that `TIME_MONOTONIC_RAW` would be supported by a sufficiently large set of C libraries as an extension in the near future. `CLOCK_MONOTONIC_RAW` as all the others beyond `CLOCK_THREAD_CPUTIME_ID` is a Linux extension. Only the new optional time bases in C23 are those that are already standardized in POSIX. That would be sensible only if - C libraries that implement C23 would start to support the optional time base `TIME_MONOTONIC` - You would convince yourself and the users of this code that you don't need `TIME_MONOTONIC_RAW` and may use `TIME_MONOTONIC` instead as a fallback. You will not know if this is feasible before the end of 2023 / beginning of 2024. The first thing to do would perhaps to work on the second point, because as said that clock is Linux specific. So before getting rid of POSIX dependencies you should get rid of Linux dependencies. Jₑₙₛ -- :: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS ::: :: :::::::::::::::::::::: gsm France : +33 651400183 :: :: ::::::::::::::: gsm international : +49 15737185122 :: :: http://icube-icps.unistra.fr/index.php/Jens_Gustedt :: [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 195 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [musl] C23 implications for C libraries 2022-11-19 14:33 ` Jₑₙₛ Gustedt 2022-11-19 17:19 ` 罗勇刚(Yonggang Luo) @ 2022-11-19 18:28 ` Rich Felker 2022-11-20 8:42 ` Jₑₙₛ Gustedt 2023-05-03 22:58 ` enh 2 siblings, 1 reply; 40+ messages in thread From: Rich Felker @ 2022-11-19 18:28 UTC (permalink / raw) To: Jₑₙₛ Gustedt Cc: 罗勇刚(Yonggang Luo), musl, Jason Ekstrand On Sat, Nov 19, 2022 at 03:33:50PM +0100, Jₑₙₛ Gustedt wrote: > 罗勇刚, > > on Sat, 19 Nov 2022 04:46:22 +0800 you (罗勇刚(Yonggang Luo) > <luoyonggang@gmail.com>) wrote: > > > There is a concept called CLOCK_MONOTONIC_RAW (since Linux 2.6.28; > > Linux-specific), > > May C2x provide TIME_MONOTONIC_RAW in future or can we just implement > > TIME_MONOTONIC with > > CLOCK_MONOTONIC_RAW on Linux? > > I am not completely sure what you are asking. C2x was the short name > for C23 when we did not yet know that it will come out in 2023. > > C23 indeed adds three *optional* time bases `TIME_MONOTONIC`, > `TIME_ACTIVE` and `TIME_THREAD_ACTIVE` which are modeled after the > POSIX clocks `CLOCK_MONOTONIC`, `CLOCK_PROCESS_CPUTIME_ID` and > `CLOCK_THREAD_CPUTIME_ID`, respectively. Using them to map to other > POSIX clocks, even if these are conceptually close, is not a good > idea, I think. > > That said, having time bases for C other than `TIME_UTC` is at the > liberty of the implementation, so musl could easily provide the > equivalent to all POSIX clocks that it interfaces. Currently these are > > #define CLOCK_REALTIME 0 > #define CLOCK_MONOTONIC 1 > #define CLOCK_PROCESS_CPUTIME_ID 2 > #define CLOCK_THREAD_CPUTIME_ID 3 > #define CLOCK_MONOTONIC_RAW 4 > #define CLOCK_REALTIME_COARSE 5 > #define CLOCK_MONOTONIC_COARSE 6 > #define CLOCK_BOOTTIME 7 > #define CLOCK_REALTIME_ALARM 8 > #define CLOCK_BOOTTIME_ALARM 9 > #define CLOCK_SGI_CYCLE 10 > #define CLOCK_TAI 11 > > This could easily be done by using > > #define TIME_UTC (CLOCK_REALTIME+1) > #define TIME_MONOTONIC (CLOCK_MONOTONIC+1) > #define TIME_ATIVE (CLOCK_PROCESS_CPUTIME_I+1) > #define TIME_THREAD_ACTIVE (CLOCK_THREAD_CPUTIME_ID+1) > #define TIME_MONOTONIC_RAW (CLOCK_MONOTONIC_RAW+1) > #define TIME_UTC_COARSE (CLOCK_REALTIME_COARSE+1) > #define TIME_MONOTONIC_COARSE (CLOCK_MONOTONIC_COARSE+1) > #define TIME_BOOTTIME (CLOCK_BOOTTIME+1) > #define TIME_UTC_ALARM (CLOCK_REALTIME_ALARM+1) > #define TIME_BOOTTIME_ALARM (CLOCK_BOOTTIME_ALARM+1) > #define TIME_SGI_CYCLE (CLOCK_SGI_CYCLE+1) > #define TIME_TAI (CLOCK_TAI+1) > > and then adapting `timespec_get` a bit. This would be conforming to > current and future C, because the `TIME_` prefix is already reserved > for that purpose. > > Unfortunately the choice of the values is an ABI choice, so before > doing so we should be sure that other C libraries on Linux use the > same values. > > (Rich: would you accept a patch that goes in that direction?) I don't see any good reason to have extension clocks in the timespec_get interface unless they're destined for standardization. It's just a risk of conflict with future standards requirements. There's really no reason at all to even use this interface rather than the POSIX one unless you're writing code that's targeting baseline C (and especially C11 threads, where having a timespec is sometimes useful for those interfaces) with the aim of also operating on non-POSIX-like implementations, and it doesn't seem like you would expect such a target to have Linux-like extension clocks. Rich ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [musl] C23 implications for C libraries 2022-11-19 18:28 ` Rich Felker @ 2022-11-20 8:42 ` Jₑₙₛ Gustedt 0 siblings, 0 replies; 40+ messages in thread From: Jₑₙₛ Gustedt @ 2022-11-20 8:42 UTC (permalink / raw) To: Rich Felker; +Cc: 罗勇刚(Yonggang Luo), musl, Jason Ekstrand [-- Attachment #1: Type: text/plain, Size: 5095 bytes --] Rich, on Sat, 19 Nov 2022 13:28:42 -0500 you (Rich Felker <dalias@libc.org>) wrote: > On Sat, Nov 19, 2022 at 03:33:50PM +0100, Jₑₙₛ Gustedt wrote: > > 罗勇刚, > > > > on Sat, 19 Nov 2022 04:46:22 +0800 you (罗勇刚(Yonggang Luo) > > <luoyonggang@gmail.com>) wrote: > > > > > There is a concept called CLOCK_MONOTONIC_RAW (since Linux > > > 2.6.28; Linux-specific), > > > May C2x provide TIME_MONOTONIC_RAW in future or can we just > > > implement TIME_MONOTONIC with > > > CLOCK_MONOTONIC_RAW on Linux? > > > > I am not completely sure what you are asking. C2x was the short name > > for C23 when we did not yet know that it will come out in 2023. > > > > C23 indeed adds three *optional* time bases `TIME_MONOTONIC`, > > `TIME_ACTIVE` and `TIME_THREAD_ACTIVE` which are modeled after the > > POSIX clocks `CLOCK_MONOTONIC`, `CLOCK_PROCESS_CPUTIME_ID` and > > `CLOCK_THREAD_CPUTIME_ID`, respectively. Using them to map to other > > POSIX clocks, even if these are conceptually close, is not a good > > idea, I think. > > > > That said, having time bases for C other than `TIME_UTC` is at the > > liberty of the implementation, so musl could easily provide the > > equivalent to all POSIX clocks that it interfaces. Currently these > > are > > > > #define CLOCK_REALTIME 0 > > #define CLOCK_MONOTONIC 1 > > #define CLOCK_PROCESS_CPUTIME_ID 2 > > #define CLOCK_THREAD_CPUTIME_ID 3 > > #define CLOCK_MONOTONIC_RAW 4 > > #define CLOCK_REALTIME_COARSE 5 > > #define CLOCK_MONOTONIC_COARSE 6 > > #define CLOCK_BOOTTIME 7 > > #define CLOCK_REALTIME_ALARM 8 > > #define CLOCK_BOOTTIME_ALARM 9 > > #define CLOCK_SGI_CYCLE 10 > > #define CLOCK_TAI 11 > > > > This could easily be done by using > > > > #define TIME_UTC (CLOCK_REALTIME+1) > > #define TIME_MONOTONIC (CLOCK_MONOTONIC+1) > > #define TIME_ATIVE (CLOCK_PROCESS_CPUTIME_I+1) > > #define TIME_THREAD_ACTIVE (CLOCK_THREAD_CPUTIME_ID+1) > > #define TIME_MONOTONIC_RAW (CLOCK_MONOTONIC_RAW+1) > > #define TIME_UTC_COARSE (CLOCK_REALTIME_COARSE+1) > > #define TIME_MONOTONIC_COARSE (CLOCK_MONOTONIC_COARSE+1) > > #define TIME_BOOTTIME (CLOCK_BOOTTIME+1) > > #define TIME_UTC_ALARM (CLOCK_REALTIME_ALARM+1) > > #define TIME_BOOTTIME_ALARM (CLOCK_BOOTTIME_ALARM+1) > > #define TIME_SGI_CYCLE (CLOCK_SGI_CYCLE+1) > > #define TIME_TAI (CLOCK_TAI+1) > > > > and then adapting `timespec_get` a bit. This would be conforming to > > current and future C, because the `TIME_` prefix is already reserved > > for that purpose. > > > > Unfortunately the choice of the values is an ABI choice, so before > > doing so we should be sure that other C libraries on Linux use the > > same values. > > > > (Rich: would you accept a patch that goes in that direction?) > > I don't see any good reason to have extension clocks in the > timespec_get interface unless they're destined for standardization. > It's just a risk of conflict with future standards requirements. Ok, I see your point, kind of, but we could still interface these by appending `_NP` or so to the name. This is low cost service to maybe some users. And the Linux extensions will not go away, so there should not be any extra burden by doing so. Put that questions about extensions aside, three of them become options in C23. So for those there is no reason to hold back, right? > There's really no reason at all to even use this interface rather than > the POSIX one unless you're writing code that's targeting baseline C > (and especially C11 threads, where having a timespec is sometimes > useful for those interfaces) with the aim of also operating on > non-POSIX-like implementations, and it doesn't seem like you would > expect such a target to have Linux-like extension clocks. For the usefulness of the C thread interface, I don't agree. That interface is much simpler and tamer than the POSIX interface and completely sufficient for a large spectrum of applications. Of what I observed 80% of the effort of implementing POSIX threads in musl went into the necessary support of thread cancelation. This is a large source of problems, bugs and maybe even slight performance costs. Then for the usefulness of the `timespec` interfaces this is exactly the point. These only become useful if per default there are more time bases supported, such that they can replace the other cryptic interfaces for timing (such as the non-portable `clock` function) that we inherited from the elders. Therefore C23 also adds `timespec_getres` such that applications have a sensible way of using these for timing, independently of the thread interface. Thanks Jₑₙₛ -- :: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS ::: :: :::::::::::::::::::::: gsm France : +33 651400183 :: :: ::::::::::::::: gsm international : +49 15737185122 :: :: http://icube-icps.unistra.fr/index.php/Jens_Gustedt :: [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 195 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [musl] C23 implications for C libraries 2022-11-19 14:33 ` Jₑₙₛ Gustedt 2022-11-19 17:19 ` 罗勇刚(Yonggang Luo) 2022-11-19 18:28 ` Rich Felker @ 2023-05-03 22:58 ` enh 2023-05-04 6:19 ` Jₑₙₛ Gustedt 2 siblings, 1 reply; 40+ messages in thread From: enh @ 2023-05-03 22:58 UTC (permalink / raw) To: musl; +Cc: 罗勇刚(Yonggang Luo), Jason Ekstrand [-- Attachment #1: Type: text/plain, Size: 4282 bytes --] On Sat, Nov 19, 2022 at 6:34 AM Jₑₙₛ Gustedt <jens.gustedt@inria.fr> wrote: > 罗勇刚, > > on Sat, 19 Nov 2022 04:46:22 +0800 you (罗勇刚(Yonggang Luo) > <luoyonggang@gmail.com>) wrote: > > > There is a concept called CLOCK_MONOTONIC_RAW (since Linux 2.6.28; > > Linux-specific), > > May C2x provide TIME_MONOTONIC_RAW in future or can we just implement > > TIME_MONOTONIC with > > CLOCK_MONOTONIC_RAW on Linux? > > I am not completely sure what you are asking. C2x was the short name > for C23 when we did not yet know that it will come out in 2023. > > C23 indeed adds three *optional* time bases `TIME_MONOTONIC`, > `TIME_ACTIVE` and `TIME_THREAD_ACTIVE` which are modeled after the > POSIX clocks `CLOCK_MONOTONIC`, `CLOCK_PROCESS_CPUTIME_ID` and > `CLOCK_THREAD_CPUTIME_ID`, respectively. Using them to map to other > POSIX clocks, even if these are conceptually close, is not a good > idea, I think. > > That said, having time bases for C other than `TIME_UTC` is at the > liberty of the implementation, so musl could easily provide the > equivalent to all POSIX clocks that it interfaces. Currently these are > > #define CLOCK_REALTIME 0 > #define CLOCK_MONOTONIC 1 > #define CLOCK_PROCESS_CPUTIME_ID 2 > #define CLOCK_THREAD_CPUTIME_ID 3 > #define CLOCK_MONOTONIC_RAW 4 > #define CLOCK_REALTIME_COARSE 5 > #define CLOCK_MONOTONIC_COARSE 6 > #define CLOCK_BOOTTIME 7 > #define CLOCK_REALTIME_ALARM 8 > #define CLOCK_BOOTTIME_ALARM 9 > #define CLOCK_SGI_CYCLE 10 > #define CLOCK_TAI 11 > > This could easily be done by using > > #define TIME_UTC (CLOCK_REALTIME+1) > #define TIME_MONOTONIC (CLOCK_MONOTONIC+1) > #define TIME_ATIVE (CLOCK_PROCESS_CPUTIME_I+1) > #define TIME_THREAD_ACTIVE (CLOCK_THREAD_CPUTIME_ID+1) > #define TIME_MONOTONIC_RAW (CLOCK_MONOTONIC_RAW+1) > #define TIME_UTC_COARSE (CLOCK_REALTIME_COARSE+1) > #define TIME_MONOTONIC_COARSE (CLOCK_MONOTONIC_COARSE+1) > #define TIME_BOOTTIME (CLOCK_BOOTTIME+1) > #define TIME_UTC_ALARM (CLOCK_REALTIME_ALARM+1) > #define TIME_BOOTTIME_ALARM (CLOCK_BOOTTIME_ALARM+1) > #define TIME_SGI_CYCLE (CLOCK_SGI_CYCLE+1) > #define TIME_TAI (CLOCK_TAI+1) > > and then adapting `timespec_get` a bit. This would be conforming to > current and future C, because the `TIME_` prefix is already reserved > for that purpose. > (i share others' skepticism that timespec_get() is very useful, 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.) > Unfortunately the choice of the values is an ABI choice, so before > doing so we should be sure that other C libraries on Linux use the > same values. > > (Rich: would you accept a patch that goes in that direction?) > > > When implement mesa vulkan driver, > > it's ask for CLOCK_MONOTONIC_RAW at > > > > > https://gitlab.freedesktop.org/mesa/mesa/-/blob/c6c5949ff70a47c47795fe9161a7514173b5be24/src/vulkan/runtime/vk_device.c#L557 > > > > May intention is using C2x timespec_get > > to replace function > > vk_clock_gettime but it's lack of TIME_MONOTONIC_RAW, so I don't know > > what's the best way > > I am not sure why you'd want to do this, are you trying to port that > code such that it gets rid of any reference to POSIX interfaces? If > so, you'd have to wait and see if other C libraries will interface the > "new" time bases that C23 specifies. (Or does your code only run with > musl or windows?) > > Then to know if a fallback to `CLOCK_MONOTONIC_RAW` is sensible, you > would have to inspect for which clocks the current function is really > used and if fallback is even needed in real life. > > Jₑₙₛ > > -- > :: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS ::: > :: :::::::::::::::::::::: gsm France : +33 651400183 > <+33%206%2051%2040%2001%2083> :: > :: ::::::::::::::: gsm international : +49 15737185122 > <+49%201573%207185122> :: > :: http://icube-icps.unistra.fr/index.php/Jens_Gustedt :: > [-- Attachment #2: Type: text/html, Size: 5571 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [musl] C23 implications for C libraries 2023-05-03 22:58 ` enh @ 2023-05-04 6:19 ` Jₑₙₛ Gustedt 2023-05-04 16:03 ` Rich Felker 2023-05-04 16:03 ` enh 0 siblings, 2 replies; 40+ messages in thread From: Jₑₙₛ Gustedt @ 2023-05-04 6:19 UTC (permalink / raw) To: enh; +Cc: musl, 罗勇刚(Yonggang Luo), Jason Ekstrand [-- Attachment #1: Type: text/plain, Size: 1406 bytes --] 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? 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 :: [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 195 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [musl] C23 implications for C libraries 2023-05-04 6:19 ` Jₑₙₛ Gustedt @ 2023-05-04 16:03 ` Rich Felker 2023-05-04 16:07 ` enh 2023-05-04 16:03 ` enh 1 sibling, 1 reply; 40+ messages in thread From: Rich Felker @ 2023-05-04 16:03 UTC (permalink / raw) To: Jₑₙₛ Gustedt Cc: enh, musl, 罗勇刚(Yonggang Luo), Jason Ekstrand 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. But I'm open to discussion. Rich ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [musl] C23 implications for C libraries 2023-05-04 16:03 ` Rich Felker @ 2023-05-04 16:07 ` enh 2023-05-04 23:16 ` Gabriel Ravier 2023-05-05 6:40 ` Jₑₙₛ Gustedt 0 siblings, 2 replies; 40+ messages in thread From: enh @ 2023-05-04 16:07 UTC (permalink / raw) To: Rich Felker Cc: Jₑₙₛ Gustedt, musl, 罗勇刚(Yonggang Luo), Jason Ekstrand [-- Attachment #1: Type: text/plain, Size: 2036 bytes --] 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*) > But I'm open to discussion. > > Rich > [-- Attachment #2: Type: text/html, Size: 2783 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [musl] C23 implications for C libraries 2023-05-04 16:07 ` enh @ 2023-05-04 23:16 ` Gabriel Ravier 2023-05-05 0:37 ` JeanHeyd Meneide 2023-05-05 6:40 ` Jₑₙₛ Gustedt 1 sibling, 1 reply; 40+ messages in thread From: Gabriel Ravier @ 2023-05-04 23:16 UTC (permalink / raw) To: musl, enh, Rich Felker Cc: Jₑₙₛ Gustedt, 罗勇刚(Yonggang Luo), Jason Ekstrand [-- Attachment #1: Type: text/plain, Size: 2645 bytes --] 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 > [-- Attachment #2: Type: text/html, Size: 4880 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [musl] C23 implications for C libraries 2023-05-04 23:16 ` Gabriel Ravier @ 2023-05-05 0:37 ` JeanHeyd Meneide 2023-05-05 6:56 ` Jₑₙₛ Gustedt 0 siblings, 1 reply; 40+ messages in thread From: JeanHeyd Meneide @ 2023-05-05 0:37 UTC (permalink / raw) To: musl Cc: enh, Rich Felker, Jₑₙₛ Gustedt, 罗勇刚(Yonggang Luo), Jason Ekstrand [-- Attachment #1: Type: text/plain, Size: 927 bytes --] > 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. There was apparently one implementation that was already using %B as a kind of numeric printout (not for binary) that was reported during the meeting and at a few other junctures, so unfortunately it might not be fully portable. But, I think that for that implementation it's flag-guarded (though on by default). It'd be great if I remembered the name of the implementation (but the meeting this was discussed in was... over a year ago now? So I'd have to go back and refresh my memory). If I do remember, I thought to myself that I might send an e-mail asking them if they would feel okay with aligning their library with the standard's recommendations. Couldn't hurt to ask, right? - JeanHeyd [-- Attachment #2: Type: text/html, Size: 1092 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [musl] C23 implications for C libraries 2023-05-05 0:37 ` JeanHeyd Meneide @ 2023-05-05 6:56 ` Jₑₙₛ Gustedt 2023-05-05 12:40 ` Rich Felker 0 siblings, 1 reply; 40+ messages in thread From: Jₑₙₛ Gustedt @ 2023-05-05 6:56 UTC (permalink / raw) To: JeanHeyd Meneide Cc: musl, enh, Rich Felker, 罗勇刚(Yonggang Luo), Jason Ekstrand [-- Attachment #1: Type: text/plain, Size: 1647 bytes --] Hello, on Thu, 4 May 2023 20:37:58 -0400 you (JeanHeyd Meneide <phdofthehouse@gmail.com>) wrote: > > 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. > > There was apparently one implementation that was already using > %B as a kind of numeric printout (not for binary) that was reported > during the meeting and at a few other junctures, so unfortunately it > might not be fully portable. … Yes, in general I am always amazed to see how diversive and inventive C implementations are. So changing things even as innocent sounding like a format specifier or adding new function identifiers that could be conflicting with applications is usually watched very closely. There are really a lot of C implementations out there, and in general they use the design space that is offered to them. For format specifiers this is even more complicated. There are C libraries that provide interfaces to add such specifiers from user space. So here the risk for conflicts can not easily be assessed by WG14 (we don't have the data). So it should be left to the C library implementors to assess this risk. 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 :: [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 195 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [musl] C23 implications for C libraries 2023-05-05 6:56 ` Jₑₙₛ Gustedt @ 2023-05-05 12:40 ` Rich Felker 0 siblings, 0 replies; 40+ messages in thread From: Rich Felker @ 2023-05-05 12:40 UTC (permalink / raw) To: Jₑₙₛ Gustedt Cc: JeanHeyd Meneide, musl, enh, 罗勇刚(Yonggang Luo), Jason Ekstrand On Fri, May 05, 2023 at 08:56:41AM +0200, Jₑₙₛ Gustedt wrote: > Hello, > > on Thu, 4 May 2023 20:37:58 -0400 you (JeanHeyd Meneide > <phdofthehouse@gmail.com>) wrote: > > > > 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. > > > > There was apparently one implementation that was already using > > %B as a kind of numeric printout (not for binary) that was reported > > during the meeting and at a few other junctures, so unfortunately it > > might not be fully portable. … > > Yes, in general I am always amazed to see how diversive and inventive > C implementations are. So changing things even as innocent sounding > like a format specifier or adding new function identifiers that could > be conflicting with applications is usually watched very > closely. There are really a lot of C implementations out there, and > in general they use the design space that is offered to them. > > For format specifiers this is even more complicated. There are C > libraries that provide interfaces to add such specifiers from user > space. So here the risk for conflicts can not easily be assessed by > WG14 (we don't have the data). So it should be left to the C library > implementors to assess this risk. FWIW, from the musl side, my assessment of this risk is that it makes no sense at all. The features you get are accessible only with hard-coded knowledge of your implementation; they aren't even detectable via probing. And unless you're a behemoth with effective veto power, there's always a risk that future official or de facto standards will impose conflicting requirements for whatever you assigned a custom meaning to. Rich ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [musl] C23 implications for C libraries 2023-05-04 16:07 ` enh 2023-05-04 23:16 ` Gabriel Ravier @ 2023-05-05 6:40 ` Jₑₙₛ Gustedt 1 sibling, 0 replies; 40+ messages in thread From: Jₑₙₛ Gustedt @ 2023-05-05 6:40 UTC (permalink / raw) To: enh Cc: Rich Felker, musl, 罗勇刚(Yonggang Luo), Jason Ekstrand [-- Attachment #1: Type: text/plain, Size: 1345 bytes --] enh, on Thu, 4 May 2023 09:07:30 -0700 you (enh <enh@google.com>) wrote: > only having been involved with POSIX and not WG14, doesn't the latter > take existing practice into account like the former does? In this case WG14 considers the POSIX interfaces as existing practice. We just have the problem that unfortunately in the past it was decided not to map the full feature set of the clock interfaces into C, but to somehow rename and reduce things to these `timespec` interfaces. (I was not yet there, then, but my understanding is that this was added a bit in a hurry relatively late in the process for C11.) The argument that convinced WG14 to take in these three new optional time bases is to avoid diverging practice in the future. So if somebody adds a monotonic clock (for example) to a C implementation, it should have the semantics as described. And something like that (a monotonic clock) has for example been sought by users for the thread interfaces that use time limits. 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 :: [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 195 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [musl] C23 implications for C libraries 2023-05-04 6:19 ` Jₑₙₛ Gustedt 2023-05-04 16:03 ` Rich Felker @ 2023-05-04 16:03 ` enh 2023-05-04 23:11 ` Gabriel Ravier 1 sibling, 1 reply; 40+ messages in thread From: enh @ 2023-05-04 16:03 UTC (permalink / raw) To: Jₑₙₛ Gustedt Cc: musl, 罗勇刚(Yonggang Luo), Jason Ekstrand [-- Attachment #1: Type: text/plain, Size: 2270 bytes --] 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? 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ₑₙₛ > > -- > :: ICube :::::::::::::::::::::::::::::: deputy director :: > :: Université de Strasbourg :::::::::::::::::::::: ICPS :: > :: INRIA Nancy Grand Est :::::::::::::::::::::::: Camus :: > :: :::::::::::::::::::::::::::::::::::: ☎ +33 368854536 > <+33%203%2068%2085%2045%2036> :: > :: https://icube-icps.unistra.fr/index.php/Jens_Gustedt :: > [-- Attachment #2: Type: text/html, Size: 3632 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [musl] C23 implications for C libraries 2023-05-04 16:03 ` enh @ 2023-05-04 23:11 ` Gabriel Ravier 0 siblings, 0 replies; 40+ messages in thread From: Gabriel Ravier @ 2023-05-04 23:11 UTC (permalink / raw) To: musl, enh, Jₑₙₛ Gustedt Cc: 罗勇刚(Yonggang Luo), Jason Ekstrand [-- Attachment #1: Type: text/plain, Size: 2485 bytes --] 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? > > > 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 > <tel:+33%203%2068%2085%2045%2036> :: > :: https://icube-icps.unistra.fr/index.php/Jens_Gustedt :: > [-- Attachment #2: Type: text/html, Size: 5865 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [musl] C23 implications for C libraries 2022-11-18 20:46 ` 罗勇刚(Yonggang Luo) 2022-11-19 14:33 ` Jₑₙₛ Gustedt @ 2022-11-19 18:31 ` Rich Felker 2022-11-20 4:25 ` 罗勇刚(Yonggang Luo) 1 sibling, 1 reply; 40+ messages in thread From: Rich Felker @ 2022-11-19 18:31 UTC (permalink / raw) To: 罗勇刚(Yonggang Luo); +Cc: musl, Jens Gustedt, Jason Ekstrand On Sat, Nov 19, 2022 at 04:46:22AM +0800, 罗勇刚(Yonggang Luo) wrote: > There is a concept called CLOCK_MONOTONIC_RAW (since Linux 2.6.28; > Linux-specific), > May C2x provide TIME_MONOTONIC_RAW in future or can we just implement > TIME_MONOTONIC with > CLOCK_MONOTONIC_RAW on Linux? When implement mesa vulkan driver, it's ask > for CLOCK_MONOTONIC_RAW at > > https://gitlab.freedesktop.org/mesa/mesa/-/blob/c6c5949ff70a47c47795fe9161a7514173b5be24/src/vulkan/runtime/vk_device.c#L557 > > May intention is using C2x timespec_get to replace function > vk_clock_gettime but it's lack of TIME_MONOTONIC_RAW, so I don't know > what's the best way The code there is already doing exactly what it should do in the case where CLOCK_MONOTONIC_RAW is not defined so I'm not sure what you're trying to achieve. On a system where CLOCK_MONOTONIC_RAW is defined, the caller may have (for likely-nonsensical reasons) chosen to pass CLOCK_MONOTONIC_RAW, and they're handling the case where the kernel is too old to have that extension clock by substituting CLOCK_MONOTONIC instead. If CLOCK_MONOTONIC_RAW is not defined, then most certainly the caller did not pass it (since there's no such thing) and thus there is no need for any fallback code. No action is needed at all here. Rich ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [musl] C23 implications for C libraries 2022-11-19 18:31 ` Rich Felker @ 2022-11-20 4:25 ` 罗勇刚(Yonggang Luo) 2022-11-20 5:34 ` Markus Wichmann 0 siblings, 1 reply; 40+ messages in thread From: 罗勇刚(Yonggang Luo) @ 2022-11-20 4:25 UTC (permalink / raw) To: musl, Rich Felker; +Cc: Jens Gustedt, Jason Ekstrand [-- Attachment #1: Type: text/plain, Size: 1844 bytes --] On Sun, Nov 20, 2022 at 2:32 AM Rich Felker <dalias@libc.org> wrote: > > On Sat, Nov 19, 2022 at 04:46:22AM +0800, 罗勇刚(Yonggang Luo) wrote: > > There is a concept called CLOCK_MONOTONIC_RAW (since Linux 2.6.28; > > Linux-specific), > > May C2x provide TIME_MONOTONIC_RAW in future or can we just implement > > TIME_MONOTONIC with > > CLOCK_MONOTONIC_RAW on Linux? When implement mesa vulkan driver, it's ask > > for CLOCK_MONOTONIC_RAW at > > > > https://gitlab.freedesktop.org/mesa/mesa/-/blob/c6c5949ff70a47c47795fe9161a7514173b5be24/src/vulkan/runtime/vk_device.c#L557 > > > > May intention is using C2x timespec_get to replace function > > vk_clock_gettime but it's lack of TIME_MONOTONIC_RAW, so I don't know > > what's the best way > > The code there is already doing exactly what it should do in the case > where CLOCK_MONOTONIC_RAW is not defined so I'm not sure what you're > trying to achieve. > > On a system where CLOCK_MONOTONIC_RAW is defined, the caller may have > (for likely-nonsensical reasons) chosen to pass CLOCK_MONOTONIC_RAW, > and they're handling the case where the kernel is too old to have that > extension clock by substituting CLOCK_MONOTONIC instead. That's the issue, when you access `CLOCK_MONOTONIC_RAW`, it's have to be defined, suppose we have standardized TIME_MONOTONIC_RAW, then we have no need get the time with, ``` #ifndef CLOCK_MONOTONIC_RAW // The code #endif ``` but with ``` if (timespec_get(ts, TIME_MONOTONIC_RAW) != 0) { } ``` > > If CLOCK_MONOTONIC_RAW is not defined, then most certainly the caller > did not pass it (since there's no such thing) and thus there is no > need for any fallback code. > > No action is needed at all here. > > Rich -- 此致 礼 罗勇刚 Yours sincerely, Yonggang Luo [-- Attachment #2: Type: text/html, Size: 2485 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [musl] C23 implications for C libraries 2022-11-20 4:25 ` 罗勇刚(Yonggang Luo) @ 2022-11-20 5:34 ` Markus Wichmann 0 siblings, 0 replies; 40+ messages in thread From: Markus Wichmann @ 2022-11-20 5:34 UTC (permalink / raw) To: musl; +Cc: Rich Felker, Jens Gustedt, Jason Ekstrand On Sun, Nov 20, 2022 at 12:25:21PM +0800, 罗勇刚(Yonggang Luo) wrote: > That's the issue, when you access `CLOCK_MONOTONIC_RAW`, it's have to be > defined, suppose we have > standardized TIME_MONOTONIC_RAW, then we have no need get the time with, > ``` > #ifndef CLOCK_MONOTONIC_RAW > // The code > #endif > ``` > but with > ``` > if (timespec_get(ts, TIME_MONOTONIC_RAW) != 0) { > } > ``` > > > > But the standard defines these additional clocks as optional, too, right? I'm looking at a C23 draft from Sept. 3rd, 2022, and it says in §7.29.1.3 sentence 1: "The definition macros for time bases other than TIME_UTC are optional." Meaning even a fully conforming implementation does not have to define these. Never mind the fact that TIME_MONOTONIC_RAW is not mentioned in there, ever. The implementation is allowed to add further names beginning with TIME_ to the header, but the only time bases mentioned are UTC, MONOTONIC, ACTIVE, and THREAD_ACTIVE. The Vulkan people are also likely to not want to throw away compatibility with existing libcs that are not yet C23 capable, especially for something so minor as a timestamp. The current code works only on Linux, but it works as long as libc is young enough to define the time base. The C23 time base you are proposing can only be supported if the Linux time base is also supported, so the set of libcs supporting this extension is necessarily a subset of the ones supporting the existing code. Narrowing the set of supported libcs does not seem prudent to me. Ciao, Markus ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [musl] C23 implications for C libraries 2022-09-23 14:25 [musl] C23 implications for C libraries Jₑₙₛ Gustedt ` (2 preceding siblings ...) 2022-11-18 20:46 ` 罗勇刚(Yonggang Luo) @ 2022-11-21 11:46 ` Reini Urban 2022-11-21 21:06 ` Jₑₙₛ Gustedt 3 siblings, 1 reply; 40+ messages in thread From: Reini Urban @ 2022-11-21 11:46 UTC (permalink / raw) To: musl, Jₑₙₛ Gustedt [-- Attachment #1: Type: text/plain, Size: 628 bytes --] On Fri, Sep 23, 2022 at 4:25 PM Jₑₙₛ Gustedt <jens.gustedt@inria.fr> wrote: > Hello, > I have started to compile a document that tries to collect everything > a C library needs for C23 compliance: > > > https://htmlpreview.github.io/?https://icube-forge.unistra.fr/icps/c23-library/-/raw/main/README.html > > This is by far not complete and I will try to fill the holes in the > next weeks. Let me know if you have any particular > questions/remarks/additions. > Jens, The last line has a typo: https://icube-forge.unistra.fr/icps/c23-library/-/blob/main/README.md besearch_s => bsearch_s Reini [-- Attachment #2: Type: text/html, Size: 1212 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [musl] C23 implications for C libraries 2022-11-21 11:46 ` Reini Urban @ 2022-11-21 21:06 ` Jₑₙₛ Gustedt 2022-11-23 4:31 ` 罗勇刚(Yonggang Luo) 0 siblings, 1 reply; 40+ messages in thread From: Jₑₙₛ Gustedt @ 2022-11-21 21:06 UTC (permalink / raw) To: Reini Urban; +Cc: musl [-- Attachment #1: Type: text/plain, Size: 692 bytes --] Reini, on Mon, 21 Nov 2022 12:46:37 +0100 you (Reini Urban <reini.urban@gmail.com>) wrote: > The last line has a typo: > > https://icube-forge.unistra.fr/icps/c23-library/-/blob/main/README.md > > besearch_s => bsearch_s thanks! if that were the only thing that is still missing … BTW, there is now a html page that is easier to access and to bookmark https://gustedt.gitlabpages.inria.fr/c23-library/ Thanks Jₑₙₛ -- :: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS ::: :: :::::::::::::::::::::: gsm France : +33 651400183 :: :: ::::::::::::::: gsm international : +49 15737185122 :: :: http://icube-icps.unistra.fr/index.php/Jens_Gustedt :: [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 195 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [musl] C23 implications for C libraries 2022-11-21 21:06 ` Jₑₙₛ Gustedt @ 2022-11-23 4:31 ` 罗勇刚(Yonggang Luo) 2022-11-23 8:11 ` Jₑₙₛ Gustedt 0 siblings, 1 reply; 40+ messages in thread From: 罗勇刚(Yonggang Luo) @ 2022-11-23 4:31 UTC (permalink / raw) To: musl; +Cc: Reini Urban [-- Attachment #1: Type: text/plain, Size: 1421 bytes --] I have concern about the macros guard with __cplusplus and __STDC_VERSION__ #if (__cplusplus >= 201103L) || (__STDC_VERSION__ >= 202311L) #define NULL nullptr #elif defined(__cplusplus) #define NULL 0L /* Any of 0, 0L, 0LL as wide as a void* */ #else #define NULL ((void*)0) #endif I think all of these should be guarded with #if (defined(__cplusplus) && (__cplusplus >= 201103L)) || (defined(__STDC_VERSION__) && (__STDC_VERSION__ >= 202311L)) this is safer to avoid -Wundef complain it On Tue, Nov 22, 2022 at 5:11 AM Jₑₙₛ Gustedt <jens.gustedt@inria.fr> wrote: > > Reini, > > on Mon, 21 Nov 2022 12:46:37 +0100 you (Reini Urban > <reini.urban@gmail.com>) wrote: > > > The last line has a typo: > > > > https://icube-forge.unistra.fr/icps/c23-library/-/blob/main/README.md > > > > besearch_s => bsearch_s > > thanks! if that were the only thing that is still missing … > > BTW, there is now a html page that is easier to access and to bookmark > > https://gustedt.gitlabpages.inria.fr/c23-library/ > > Thanks > Jₑₙₛ > > -- > :: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS ::: > :: :::::::::::::::::::::: gsm France : +33 651400183 :: > :: ::::::::::::::: gsm international : +49 15737185122 :: > :: http://icube-icps.unistra.fr/index.php/Jens_Gustedt :: -- 此致 礼 罗勇刚 Yours sincerely, Yonggang Luo [-- Attachment #2: Type: text/html, Size: 2034 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [musl] C23 implications for C libraries 2022-11-23 4:31 ` 罗勇刚(Yonggang Luo) @ 2022-11-23 8:11 ` Jₑₙₛ Gustedt 2022-11-23 8:20 ` 罗勇刚(Yonggang Luo) 0 siblings, 1 reply; 40+ messages in thread From: Jₑₙₛ Gustedt @ 2022-11-23 8:11 UTC (permalink / raw) To: 罗勇刚(Yonggang Luo); +Cc: musl, Reini Urban [-- Attachment #1: Type: text/plain, Size: 1417 bytes --] 罗勇刚, there might be a misunderstanding here, this page is not meant for musl alone and the example code is just that, example code. How C library implementations then do it is clearly a question of their particular coding style. on Wed, 23 Nov 2022 12:31:27 +0800 you (罗勇刚(Yonggang Luo) <luoyonggang@gmail.com>) wrote: > I have concern about the macros guard with __cplusplus and > __STDC_VERSION__ > > #if (__cplusplus >= 201103L) || (__STDC_VERSION__ >= 202311L) > #define NULL nullptr > #elif defined(__cplusplus) > #define NULL 0L /* Any of 0, 0L, 0LL as wide as a void* > */ #else > #define NULL ((void*)0) > #endif > > > I think all of these should be guarded with > #if (defined(__cplusplus) && (__cplusplus >= 201103L)) || > (defined(__STDC_VERSION__) && (__STDC_VERSION__ >= 202311L)) > > this is safer to avoid -Wundef complain it IIRC musl's strategy has so far been to use the implicit 0 rule for identifiers in preprocessor conditionals. But I may be mistaken. Also, `__STDC_VERSION__` has been introduced in C95, I think, do we even support compilers that don't have this? Thanks Jₑₙₛ -- :: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS ::: :: :::::::::::::::::::::: gsm France : +33 651400183 :: :: ::::::::::::::: gsm international : +49 15737185122 :: :: http://icube-icps.unistra.fr/index.php/Jens_Gustedt :: [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 195 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [musl] C23 implications for C libraries 2022-11-23 8:11 ` Jₑₙₛ Gustedt @ 2022-11-23 8:20 ` 罗勇刚(Yonggang Luo) 2022-11-23 8:33 ` Jₑₙₛ Gustedt 0 siblings, 1 reply; 40+ messages in thread From: 罗勇刚(Yonggang Luo) @ 2022-11-23 8:20 UTC (permalink / raw) To: Jₑₙₛ Gustedt; +Cc: musl, Reini Urban [-- Attachment #1: Type: text/plain, Size: 1818 bytes --] On Wed, Nov 23, 2022 at 4:11 PM Jₑₙₛ Gustedt <jens.gustedt@inria.fr> wrote: > > 罗勇刚, > there might be a misunderstanding here, this page is not meant for > musl alone and the example code is just that, example code. How C > library implementations then do it is clearly a question of their > particular coding style. > > on Wed, 23 Nov 2022 12:31:27 +0800 you (罗勇刚(Yonggang Luo) > <luoyonggang@gmail.com>) wrote: > > > I have concern about the macros guard with __cplusplus and > > __STDC_VERSION__ > > > > #if (__cplusplus >= 201103L) || (__STDC_VERSION__ >= 202311L) > > #define NULL nullptr > > #elif defined(__cplusplus) > > #define NULL 0L /* Any of 0, 0L, 0LL as wide as a void* > > */ #else > > #define NULL ((void*)0) > > #endif > > > > > > I think all of these should be guarded with > > #if (defined(__cplusplus) && (__cplusplus >= 201103L)) || > > (defined(__STDC_VERSION__) && (__STDC_VERSION__ >= 202311L)) > > > > this is safer to avoid -Wundef complain it > > IIRC musl's strategy has so far been to use the implicit 0 rule for > identifiers in preprocessor conditionals. But I may be mistaken. > > Also, `__STDC_VERSION__` has been introduced in C95, I think, do we > even support compilers that don't have this? It's not because the compiler, it's because: * when compiling C code, __cplusplus is not defined, * when compiling C++ code, __STDC_VERSION__ is not defined > > Thanks > Jₑₙₛ > > -- > :: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS ::: > :: :::::::::::::::::::::: gsm France : +33 651400183 :: > :: ::::::::::::::: gsm international : +49 15737185122 :: > :: http://icube-icps.unistra.fr/index.php/Jens_Gustedt :: -- 此致 礼 罗勇刚 Yours sincerely, Yonggang Luo [-- Attachment #2: Type: text/html, Size: 2365 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [musl] C23 implications for C libraries 2022-11-23 8:20 ` 罗勇刚(Yonggang Luo) @ 2022-11-23 8:33 ` Jₑₙₛ Gustedt 2022-11-23 8:41 ` 罗勇刚(Yonggang Luo) 0 siblings, 1 reply; 40+ messages in thread From: Jₑₙₛ Gustedt @ 2022-11-23 8:33 UTC (permalink / raw) To: 罗勇刚(Yonggang Luo); +Cc: musl, Reini Urban [-- Attachment #1: Type: text/plain, Size: 764 bytes --] 罗勇刚, on Wed, 23 Nov 2022 16:20:39 +0800 you (罗勇刚(Yonggang Luo) <luoyonggang@gmail.com>) wrote: > It's not because the compiler, it's because: > * when compiling C code, __cplusplus is not defined, > * when compiling C++ code, __STDC_VERSION__ is not defined sure As I said, this is a policy decision of the corresponding C library implementation. Whatever musl's policy here is, they will use that. (If even in that case, because changes to `NULL` are not mandatory.) Thanks Jₑₙₛ -- :: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS ::: :: :::::::::::::::::::::: gsm France : +33 651400183 :: :: ::::::::::::::: gsm international : +49 15737185122 :: :: http://icube-icps.unistra.fr/index.php/Jens_Gustedt :: [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 195 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [musl] C23 implications for C libraries 2022-11-23 8:33 ` Jₑₙₛ Gustedt @ 2022-11-23 8:41 ` 罗勇刚(Yonggang Luo) 0 siblings, 0 replies; 40+ messages in thread From: 罗勇刚(Yonggang Luo) @ 2022-11-23 8:41 UTC (permalink / raw) To: Jₑₙₛ Gustedt; +Cc: musl, Reini Urban [-- Attachment #1: Type: text/plain, Size: 1326 bytes --] On Wed, Nov 23, 2022 at 4:33 PM Jₑₙₛ Gustedt <jens.gustedt@inria.fr> wrote: > > 罗勇刚, > > on Wed, 23 Nov 2022 16:20:39 +0800 you (罗勇刚(Yonggang Luo) > <luoyonggang@gmail.com>) wrote: > > > It's not because the compiler, it's because: > > * when compiling C code, __cplusplus is not defined, > > * when compiling C++ code, __STDC_VERSION__ is not defined > > sure > > As I said, this is a policy decision of the corresponding C library > implementation. Whatever musl's policy here is, they will use > that. (If even in that case, because changes to `NULL` are not > mandatory.) I am not worried about musl, just worried that someone else copied the code from https://gustedt.gitlabpages.inria.fr/c23-library/ and leading to -Wundef, as c23 won't be usable in near future by standard library, and people want c23 will polyfill it and reference https://gustedt.gitlabpages.inria.fr/c23-library/, that's what I am worried. > > Thanks > Jₑₙₛ > > -- > :: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS ::: > :: :::::::::::::::::::::: gsm France : +33 651400183 :: > :: ::::::::::::::: gsm international : +49 15737185122 :: > :: http://icube-icps.unistra.fr/index.php/Jens_Gustedt :: -- 此致 礼 罗勇刚 Yours sincerely, Yonggang Luo [-- Attachment #2: Type: text/html, Size: 1893 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
end of thread, other threads:[~2023-05-05 12:40 UTC | newest] Thread overview: 40+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-09-23 14:25 [musl] C23 implications for C libraries Jₑₙₛ Gustedt 2022-09-23 14:58 ` Rich Felker 2022-09-23 15:11 ` Alexander Monakov 2022-09-23 15:35 ` Jₑₙₛ Gustedt 2022-09-23 15:28 ` enh 2022-09-23 15:40 ` Jₑₙₛ Gustedt 2022-09-23 23:52 ` enh 2022-09-24 7:31 ` Jₑₙₛ Gustedt 2022-09-26 3:18 ` Damian McGuckin 2022-09-26 3:33 ` Rich Felker 2022-09-26 10:49 ` Florian Weimer 2022-09-26 12:52 ` Jₑₙₛ Gustedt 2022-09-26 20:13 ` enh 2022-11-18 20:46 ` 罗勇刚(Yonggang Luo) 2022-11-19 14:33 ` Jₑₙₛ Gustedt 2022-11-19 17:19 ` 罗勇刚(Yonggang Luo) 2022-11-20 8:23 ` Jₑₙₛ Gustedt 2022-11-19 18:28 ` Rich Felker 2022-11-20 8:42 ` Jₑₙₛ Gustedt 2023-05-03 22:58 ` enh 2023-05-04 6:19 ` Jₑₙₛ Gustedt 2023-05-04 16:03 ` Rich Felker 2023-05-04 16:07 ` enh 2023-05-04 23:16 ` Gabriel Ravier 2023-05-05 0:37 ` JeanHeyd Meneide 2023-05-05 6:56 ` Jₑₙₛ Gustedt 2023-05-05 12:40 ` Rich Felker 2023-05-05 6:40 ` Jₑₙₛ Gustedt 2023-05-04 16:03 ` enh 2023-05-04 23:11 ` Gabriel Ravier 2022-11-19 18:31 ` Rich Felker 2022-11-20 4:25 ` 罗勇刚(Yonggang Luo) 2022-11-20 5:34 ` Markus Wichmann 2022-11-21 11:46 ` Reini Urban 2022-11-21 21:06 ` Jₑₙₛ Gustedt 2022-11-23 4:31 ` 罗勇刚(Yonggang Luo) 2022-11-23 8:11 ` Jₑₙₛ Gustedt 2022-11-23 8:20 ` 罗勇刚(Yonggang Luo) 2022-11-23 8:33 ` Jₑₙₛ Gustedt 2022-11-23 8:41 ` 罗勇刚(Yonggang Luo)
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/musl/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).