Re: [musl] C23 implications for C libraries

[Gabriel Ravier <gabravier@gmail.com>]

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

On 5/4/23 18:07, enh wrote:
>
>
> 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*)
Clearly this isn't the case for at least some things they declare 
optional, unless you think types like uint32_t or uintptr_t are useless. 
In any case, I'm pretty sure they take existing practice into account - 
for example, stuff like the %B specifier are technically optional given 
that the uppercase conversion specifier namespace wasn't reserved, but 
iirc there's no known implementation of C that uses it for any other 
purpose.
>
>     But I'm open to discussion.
>
>     Rich
>

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