APIs in New POSIX Edition
Thu Apr 8 11:38:58 GMT 2021
On Thu, Apr 8, 2021, 6:19 AM Corinna Vinschen <email@example.com> wrote:
> On Apr 7 18:26, Joel Sherrill wrote:
> > Hi
> > https://www.opengroup.org/austin/docs/austin_1110.pdf includes a set of
> > 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
> > 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
> > 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.
What feature guard should these be behind? Will it change for the ones
already in place?
More information about the Newlib