APIs in New POSIX Edition

[Joel Sherrill]

On Thu, Apr 8, 2021, 6:19 AM Corinna Vinschen <vinschen@redhat.com> wrote:

> On Apr  7 18:26, Joel Sherrill wrote:
> > Hi
> >
> > https://www.opengroup.org/austin/docs/austin_1110.pdf includes a set of
> new
> > methods to be added to the POSIX standard. RTEMS has a potential GSoC
> > student interested in working down the list for RTEMS. Some of these make
> > sense to be implemented in newlib. All will end up being prototyped in
> > newlib headers somewhere.
> >
> > >From the document and the formatting is completely lost.
> >
> >  The additional APIs proposed by participants in the Austin Group that
> The
> > Open Group has agreed to sponsor are as follows:
>
> > getentropy()
> > memmem()
> > reallocarray()
> > strlcat()
> > strlcpy()
> > wcslcat()
> > wcslcpy()
>
> Already in newlib.
>
> > ppoll()
>
> Already defined in Cygwin.  We don't have a generic poll.h header in
> newlib.
>
> > dladdr()
>
> Already defined in Cygwin.  We don't have a generic dlfcn.h header in
> newlib.  It's questionable if this really belongs in newlib.
>
> > getlocalename_l()
> > posix_getdents()
> > sig2str()
> > str2sig()
>
> No worries as soon as the API is stable.
>
> > pthread_cond_clockwait()
> > pthread_mutex_clocklock()
> > pthread_rwlock_clockrdlock()
> > pthread_rwlock_clockwrlock()
> > qsort_r()
> > sem_clockwait()
>
> No worries, these APIs won't change compared to their already
> existing implementations in GLibc.
>

Great.

What feature guard should these be behind? Will it change for the ones
already in place?


>
> Corinna
>
>