Re: [musl] C23 implications for C libraries

[enh <enh@google.com>]

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

On Thu, May 4, 2023 at 9:03 AM Rich Felker <dalias@libc.org> wrote:

> On Thu, May 04, 2023 at 08:19:42AM +0200, Jₑₙₛ Gustedt wrote:
> > Hi,
> >
> > on Wed, 3 May 2023 15:58:26 -0700 you (enh <enh@google.com>) wrote:
> >
> > > (i share others' skepticism that timespec_get() is very useful,
> >
> > I don't think that these interfaces by themselves are the most
> > interesting. The original motivation to create these interfaces stem
> > from the creation the integration of threads in to the C standard. And
> > there the monotonic and thread-specific clocks make all their sense.
> >
> > But also having process cpu usage in a well-defined interface (`clock`
> > usage is not portable for that) is a win.
> >
> > > and especially that non-ISO bases will ever be useful to anyway, but
> > > i like the idea of allowing future additions to "just work" with an
> > > old libc enough that i've implemented bionic's
> > > timespec_get()/timespec_getres() in this style.)
> >
> > Great!
> >
> > Do you have a link to that? The particular choices of values become
> > part of the ABI, sort-of. So it would be better to be consistent
> > between implementations.
> >
> > Would this motivate musl to accept patches for the optional bases that
> > come with C23? Or maybe the whole set?
>
> I'm a little bit hesitant/skeptical to do this in case the optional C
> ones eventually end up having requirements that conflict with the
> POSIX/extension ones or even just with our/Linux's implementation
> choices for them. This seems like locking ourselves into a commitment
> to support something that doesn't have a lot of motivation to exist.
>

only having been involved with POSIX and not WG14, doesn't the latter take
existing practice into account like the former does? (if they don't, it
seems like anything they declare optional is then _inherently_
non-portable, and so something they'd be better off leaving out! *cough*
annex k *cough*)


> But I'm open to discussion.
>
> Rich
>

[-- Attachment #2: Type: text/html, Size: 2783 bytes --]