Re: [musl] C23 implications for C libraries

[enh <enh@google.com>]

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