Date: Mon, 26 Sep 2022 13:13:35 -0700 From: enh <enh@...gle.com> To: Jₑₙₛ Gustedt <jens.gustedt@...ia.fr> Cc: musl@...ts.openwall.com Subject: Re: C23 implications for C libraries On Sat, Sep 24, 2022 at 12:31 AM Jₑₙₛ Gustedt <jens.gustedt@...ia.fr> wrote: > enh, > > on Fri, 23 Sep 2022 16:52:53 -0700 you (enh <enh@...gle.com>) wrote: > > > On Fri, Sep 23, 2022 at 8:40 AM Jₑₙₛ Gustedt <jens.gustedt@...ia.fr> > > wrote: > > > > > enh, > > > > > > on Fri, 23 Sep 2022 08:28:52 -0700 you (enh <enh@...gle.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, 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 :: > Content of type "text/html" skipped
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.