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; 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: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 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 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 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-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-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 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-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

* 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  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         ` 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: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
  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-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-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

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).