mailing list of musl libc
 help / color / mirror / code / Atom feed
* [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; 29+ 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] 29+ 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; 29+ 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] 29+ 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; 29+ 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] 29+ 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; 29+ 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] 29+ 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; 29+ 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] 29+ 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; 29+ 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] 29+ 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; 29+ 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] 29+ 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; 29+ 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] 29+ 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; 29+ 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] 29+ 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; 29+ 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] 29+ 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; 29+ 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] 29+ 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; 29+ 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] 29+ 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; 29+ 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] 29+ 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; 29+ 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] 29+ 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)
  2022-11-19 18:28     ` Rich Felker
  2022-11-19 18:31   ` Rich Felker
  1 sibling, 2 replies; 29+ 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] 29+ 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
  1 sibling, 1 reply; 29+ 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] 29+ 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
  1 sibling, 1 reply; 29+ 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] 29+ 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; 29+ 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] 29+ 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; 29+ 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] 29+ 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; 29+ 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] 29+ 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; 29+ 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] 29+ 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; 29+ 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] 29+ 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; 29+ 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] 29+ 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; 29+ 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] 29+ 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; 29+ 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] 29+ 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; 29+ 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] 29+ 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; 29+ 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] 29+ 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; 29+ 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] 29+ 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; 29+ 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] 29+ messages in thread

end of thread, other threads:[~2022-11-23  8:42 UTC | newest]

Thread overview: 29+ 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
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).