[musl] High-level C23 process requests

[musl] High-level C23 process requests

[Rich Felker]

The C23 patches have gotten to be something of a sprawl of threads of
various review and revision work, disagreements from minor to major,
etc., and I'd like to make a couple requests for keeping this
managable to myself and other list participants:

1. Generally, we don't do the LKML-style thing of sending N related
   patches as N replies to a thread. This is really unmanagable for
   folks' inboxes, and a few people have expressed that already to me
   out-of-band. Patches are best sent in MIME form, with a set of
   related patches all attached to a single email. This makes it a lot
   easier to discuss with context that crosses individual patch
   boundaries, and for folks not interested in them to ignore them. It
   also makes it possible to keep the v2, etc. in the same thread so
   context is preserved (which isn't a hard rule or anything, but
   might help keep things organized here).

2. Extension (or "optional") functionality that's not a C23
   conformance requirement should be clearly marked as such and
   proposed separately, ideally after C23 work is merged so that
   there's not so much cognitive load here. This is the only way
   that's fair to our community to be able to engage in any sort of
   process about whether such changes move forward. Normally, when
   this kind of change is proposed, it's in isolation and clearly
   visible for folks to weigh in on, but that does not work when it's
   bundled with changes which would be automatically acceptable in
   principle as conformance requirements.

[musl] Re: High-level C23 process requests

[Jₑₙₛ Gustedt]

[-- Attachment #1: Type: text/plain, Size: 1253 bytes --]

Hello Rich,
so now your are putting the blame on me, is that it?

All the patches but for the 128 bit support are mandatory for C23.

I separated this in several threads, because *you* wanted this. At
several times I also posted a link to a git server that has all the
patches in one branch. You knew what was coming and in which threads I
planed to separate things.

Other than some years ago, I perceive this list as hostile and
patronizing, at times not engaging in real discussions but boasting
opinions that have been formed years ago and did not evolve. This is
not a place where I want to be.

On the other hand I have the impression that we are almost finished. I
will still take into account bona fide advice how to improve patches,
evidently, if there are still things to comment. Then its up to you to
take what you like and to reject what you don't. It seems that you are
the boss here.

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 --]

Re: [musl] Re: High-level C23 process requests

[Rich Felker]

On Wed, May 31, 2023 at 11:00:12PM +0200, Jₑₙₛ Gustedt wrote:
> Hello Rich,
> so now your are putting the blame on me, is that it?

I'm trying my best not to, despite being really frustrated.

> All the patches but for the 128 bit support are mandatory for C23.

OK.

> I separated this in several threads, because *you* wanted this. At
> several times I also posted a link to a git server that has all the
> patches in one branch. You knew what was coming and in which threads I
> planed to separate things.

Yes, and I still think multiple threads are fine, but what I had in
mind was a thread for each topic with posts in the thread evolving the
discussion of it, not branching for each individual patch in the set.
I never explicitly said that, though, and I'm not blaming you for not
knowing local etiquette for this list.

> Other than some years ago, I perceive this list as hostile and
> patronizing, at times not engaging in real discussions but boasting
> opinions that have been formed years ago and did not evolve. This is
> not a place where I want to be.
> 
> On the other hand I have the impression that we are almost finished. I
> will still take into account bona fide advice how to improve patches,
> evidently, if there are still things to comment. Then its up to you to
> take what you like and to reject what you don't. It seems that you are
> the boss here.

I think we're coming at this with very different goals. From what I
can gather (apologies if this turns out to be inaccurate), to you musl
looks like a place that's accessible to implement all the new things
C23 offers or allows, in a fairly straightforward way, that makes it
possible to test these things and get started with using new language
features you took part in shaping.

To myself and others in this community, though, there's mixed
sentiment towards new things. Already I've heard various comments to
the effect that folks think C23 is this big bad thing designed by
committee to impose new requirements nobody wants on implementations,
calls to boycott it, etc. That is very much NOT my view, but it's one
that comes up and that I'm stuck mediating. And new requirements often
do make it more difficult to preserve properties existing
users/community want and expect.

An important principle I go by is that a maintainer's most important
(technical) responsibility is to say no. This doesn't mean
unconditional no everywhere, but that no is the default, that
overriding existing project values and principles that a community has
come to expect requires compelling reasons and obtaining consensus. My
feeling during the whole C23 process has been that you've approached
this without any regard for that, pushing for whatever way of doing
things you would prefer, rather than what's most closely in line with
existing practices of the project you're trying to make upstreamable
changes to.

I very much appreciate and respect your work on the standardization
process and your support for and contributions to musl, but I'd be
lying if I said this present engagement isn't really frustrating to
me. As you've said, though, I think it's "almost finished", and I'll
do my best to focus on technical matters (vs style etc.) of the parts
that are appropriate and needed C23 support.

Rich

Re: [musl] Re: High-level C23 process requests

[Jₑₙₛ Gustedt]

[-- Attachment #1: Type: text/plain, Size: 4018 bytes --]

Rich,

on Wed, 31 May 2023 17:39:23 -0400 you (Rich Felker <dalias@libc.org>)
wrote:

> On Wed, May 31, 2023 at 11:00:12PM +0200, Jₑₙₛ Gustedt wrote:
> > Hello Rich,
> > so now your are putting the blame on me, is that it?  
> 
> I'm trying my best not to, despite being really frustrated.

ok

so, the frustration seems to be mutual

> ...

> I think we're coming at this with very different goals. From what I
> can gather (apologies if this turns out to be inaccurate), to you musl
> looks like a place that's accessible to implement all the new things
> C23 offers or allows, in a fairly straightforward way, that makes it
> possible to test these things and get started with using new language
> features you took part in shaping.

That's at least not the whole story. I used musl to try things out,
yes, but I would never have engaged in such a project of doing the
whole C23 changes if I would not have thought that it would be
helpful.

> To myself and others in this community, though, there's mixed
> sentiment towards new things.

hm

> Already I've heard various comments to the effect that folks think
> C23 is this big bad thing designed by committee to impose new
> requirements nobody wants on implementations, calls to boycott it,
> etc.

That is surprising. WG14 put a lot (really *a lot*) of effort in
trying not to impose ABI changes and only to integrate things that
were already present in the field. You can see that from the patches I
proposed, most of it is really boring stuff that compilers, OSes or C
libraries already had as extensions. At some points standardization
implies naming changes or to do marginal things a bit differently than
they had been in the field before, I think this is part of the game.

AFAICS, there are only three mandatory new library features that were
more or less inventions

 - `printf` and `scanf` new length prefixes
 - <stdbit.h>
 - <stdckdint.h>

Where the latter isn't even really a library feature but a language
feature interfaced with a header.

As I already said, the principal goal of the first was to go around
the `intmax_t` ABI freeze.

The second comes from very explicit users requests, and a lot of this
is already present in compilers as builtins.  Users actually wanted to
have much more than there is in this header, now, but we weren't able
to finish them in time.

Also, in the compiler community there does not seem to be much of a
resistance to implement C23. clang and gcc are almost complete and
probably will have all of C23 the day it will be officially
published. They will then probably switch to C23 as a default one or
two versions later, once the C library support is stable.

> That is very much NOT my view, but it's one that comes up and that
> I'm stuck mediating. And new requirements often do make it more
> difficult to preserve properties existing users/community want and
> expect.

The new possibility of optionally supporting `[u]int128_t` is also an
explicit user request. You might not have encountered it within musl's
community, but it is real.

> ...

> I very much appreciate and respect your work on the standardization
> process and your support for and contributions to musl, but I'd be
> lying if I said this present engagement isn't really frustrating to
> me. As you've said, though, I think it's "almost finished", and I'll
> do my best to focus on technical matters (vs style etc.) of the parts
> that are appropriate and needed C23 support.

We do agree then at least on that part. So I am looking forward for
any such technical matters that you still might want to raise.

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 --]

Re: [musl] Re: High-level C23 process requests

[Szabolcs Nagy]

* Jₑₙₛ Gustedt <jens.gustedt@inria.fr> [2023-06-01 08:58:42 +0200]:
> Also, in the compiler community there does not seem to be much of a
> resistance to implement C23. clang and gcc are almost complete and
> probably will have all of C23 the day it will be officially
> published. They will then probably switch to C23 as a default one or
> two versions later, once the C library support is stable.

well clang had _BitInt before it was in the standard.. which is a bit
of a problem because ppl only now realize that its abi is not what they
want so various targets try to retroactively specify the ps abi for it
which may leave existing clang broken.

in any case i think standard conformance is a good thing in musl, but
we are not in a big hurry to implement c23, and can wait until clang
and gcc converge on abi for a couple of targets.

Re: [musl] Re: High-level C23 process requests

[Jₑₙₛ Gustedt]

[-- Attachment #1: Type: text/plain, Size: 3107 bytes --]

Szabolcs,

on Thu, 1 Jun 2023 20:22:23 +0200 you (Szabolcs Nagy <nsz@port70.net>)
wrote:

> * Jₑₙₛ Gustedt <jens.gustedt@inria.fr> [2023-06-01 08:58:42 +0200]:
> > Also, in the compiler community there does not seem to be much of a
> > resistance to implement C23. clang and gcc are almost complete and
> > probably will have all of C23 the day it will be officially
> > published. They will then probably switch to C23 as a default one or
> > two versions later, once the C library support is stable.  
> 
> well clang had _BitInt before it was in the standard..

this is just the hen-and-egg problem

WG14 wouldn't standardize if there is no experience in the field, the
field wouldn't dare to do anything novel if this is not imposed by
some standard. So glitches like that are built into the process,
luckily the clang people took the risk and went ahead to start it. (And
they paid quite a price, having to rename the type, for example.)

> which is a bit of a problem because ppl only now realize that its
> abi is not what they want so various targets try to retroactively
> specify the ps abi for it which may leave existing clang broken.

yes

This is also the principal reason, I think, why C23 doesn't impose
function interfaces for these types, not even `printf` or `scanf`
formats, nor for the new <stdbit.h> header. So all C libraries such as
musl that delegate `va_arg` to compiler buitins should not be affected
by this.

> in any case i think standard conformance is a good thing in musl, but
> we are not in a big hurry to implement c23, and can wait until clang
> and gcc converge on abi for a couple of targets.

As said, these ABI questions are not impacting C libraries. So I don't
see how this would be an argument for (or against) integrating the
things that we have, in particular the boring stuff. I am still much
in favor to integrate this as soon as it is ready, be it for the
simple reason to never talk about it again.

Since I have your attention, there is also other "boring" stuff that I
have not even tried to implement, most things concerning floating
point functions. These are

           acospi, asinpi, atan2pi, atanpi, compoundn, cospi,
           fmaximum_mag_num, fmaximum_mag, fmaximum_num, fmaximum,
           fminimum_mag_num, fminimum_mag, fminimum_num, fminimum,
           nextup, rootn, roundeven, sinpi, tanpi, fadd, dadd, fsub,
           dsub, fmul, dmul, fdiv, ddiv

which get the usual three function interfaces and the tg-macro in
<tgmath.h>. For someone with experience in FP like you these are
probably not a big deal, it is just that there are finally a lot more
than I thought. I personnally don't think that I have the skills for
these functions.


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 --]