APIs in New POSIX Edition

[Corinna Vinschen]

On Apr  8 13:49, Corinna Vinschen wrote:
> On Apr  8 06:38, Joel Sherrill wrote:
> > 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?
> 
> There will be a matching POSIX.1-2021 or so, given by date/month,
> with guards along the lines of _POSIX_C_SOURCE >= 202107L.
> 
> APIS we already have should keep their current guard or'ed with
> the above _POSIX_C_SOURCE test.
> 
> APIs we already have but have no guard should get _DEFAULT_SOURCE
> or'ed with the above _POSIX_C_SOURCE test.

There are also APIs which already exist per an older POSIX version,
but which are not guarded.  I. e., the sem_xxx functions manipulating
POSIX semaphores.  Those don't need aguard, because they have been
introduced in conjunction with their own header, i. e., semaphore.h.

In these cases, the already existing ones still don't need a guard,
just APIs added to the header will get the new _POSIX_C_SOURCE test.

I think...


Corinna


> 
> 
> Yaakov?  Does that make sense?
> 
> 
> Thanks,
> Corinna