* [musl] High-level C23 process requests @ 2023-05-31 19:59 Rich Felker 2023-05-31 21:00 ` [musl] " Jₑₙₛ Gustedt 0 siblings, 1 reply; 6+ messages in thread From: Rich Felker @ 2023-05-31 19:59 UTC (permalink / raw) To: Jens Gustedt; +Cc: musl 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* [musl] Re: High-level C23 process requests 2023-05-31 19:59 [musl] High-level C23 process requests Rich Felker @ 2023-05-31 21:00 ` Jₑₙₛ Gustedt 2023-05-31 21:39 ` Rich Felker 0 siblings, 1 reply; 6+ messages in thread From: Jₑₙₛ Gustedt @ 2023-05-31 21:00 UTC (permalink / raw) To: Rich Felker; +Cc: musl [-- 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 --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [musl] Re: High-level C23 process requests 2023-05-31 21:00 ` [musl] " Jₑₙₛ Gustedt @ 2023-05-31 21:39 ` Rich Felker 2023-06-01 6:58 ` Jₑₙₛ Gustedt 0 siblings, 1 reply; 6+ messages in thread From: Rich Felker @ 2023-05-31 21:39 UTC (permalink / raw) To: Jₑₙₛ Gustedt; +Cc: musl 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [musl] Re: High-level C23 process requests 2023-05-31 21:39 ` Rich Felker @ 2023-06-01 6:58 ` Jₑₙₛ Gustedt 2023-06-01 18:22 ` Szabolcs Nagy 0 siblings, 1 reply; 6+ messages in thread From: Jₑₙₛ Gustedt @ 2023-06-01 6:58 UTC (permalink / raw) To: Rich Felker; +Cc: musl [-- 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 --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [musl] Re: High-level C23 process requests 2023-06-01 6:58 ` Jₑₙₛ Gustedt @ 2023-06-01 18:22 ` Szabolcs Nagy 2023-06-02 7:58 ` Jₑₙₛ Gustedt 0 siblings, 1 reply; 6+ messages in thread From: Szabolcs Nagy @ 2023-06-01 18:22 UTC (permalink / raw) To: Jₑₙₛ Gustedt; +Cc: Rich Felker, musl * 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [musl] Re: High-level C23 process requests 2023-06-01 18:22 ` Szabolcs Nagy @ 2023-06-02 7:58 ` Jₑₙₛ Gustedt 0 siblings, 0 replies; 6+ messages in thread From: Jₑₙₛ Gustedt @ 2023-06-02 7:58 UTC (permalink / raw) To: Szabolcs Nagy; +Cc: Rich Felker, musl [-- 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 --] ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2023-06-02 7:58 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2023-05-31 19:59 [musl] High-level C23 process requests Rich Felker 2023-05-31 21:00 ` [musl] " Jₑₙₛ Gustedt 2023-05-31 21:39 ` Rich Felker 2023-06-01 6:58 ` Jₑₙₛ Gustedt 2023-06-01 18:22 ` Szabolcs Nagy 2023-06-02 7:58 ` Jₑₙₛ Gustedt
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).