[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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[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 ::
>
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.
