APIs in New POSIX Edition

APIs in New POSIX Edition

[Joel Sherrill]

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: dladdr() getentropy()
getlocalename_l() memmem() posix_getdents() ppoll()
pthread_cond_clockwait() pthread_mutex_clocklock()
pthread_rwlock_clockrdlock() pthread_rwlock_clockwrlock() qsort_r()
reallocarray() sem_clockwait() sig2str() str2sig() strlcat() strlcpy()
wcslcat() wcslcpy()

What's the feeling on adding these to the headers? And if OK, what guard
should they be behind?

Thanks.

--joel

Re: APIs in New POSIX Edition

[Corinna Vinschen]

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.


Corinna

Re: 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
>
>

Re: APIs in New POSIX Edition

[Corinna Vinschen]

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.


Yaakov?  Does that make sense?


Thanks,
Corinna

Re: 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

Re: APIs in New POSIX Edition

[Corinna Vinschen]

On Apr  8 13:56, Corinna Vinschen wrote:
> On Apr  8 13:49, Corinna Vinschen wrote:
> > On Apr  8 06:38, Joel Sherrill wrote:
> > > 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...

s/_POSIX_C_SOURCE/__POSIX_VISIBLE/

and _DEFAULT_SOURCE is probably not required at all, given it's
just current POSIX anyway.  We just have to tweka the definition
of _DEFAULT_SOURCE to include the latest POSIX.

Another one: APIs from this draft already in GlibC and newlib are
guarded with __GNU_VISIBLE in newlib (e. g. memmem).  We have to change
__GNU_VISIBLE to imply the new _POSIX_C_SOURCE setting anyway, so these
symbols can be simply guarded with the new __POSIX_VISIBLE guard.

I'm sure I still forgot some situation...


Corinna

Re: APIs in New POSIX Edition

[Yaakov Selkowitz]

On Thu, 2021-04-08 at 13:49 +0200, 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.

We have to wait and see what value glibc ends up using here:

https://sourceware.org/git/?p=glibc.git;a=blob;f=include/features.h;hb=HEAD

> APIS we already have should keep their current guard or'ed with
> the above _POSIX_C_SOURCE test.

_POSIX_C_SOURCE is only externally facing, function guards will use
(__POSIX_VISIBLE >= YYYYMM).

> APIs we already have but have no guard should get _DEFAULT_SOURCE
> or'ed with the above _POSIX_C_SOURCE test.

Let's consider each such case separately.

> 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.

__POSIX_VISIBLE, but yes.


-- 
Yaakov Selkowitz
Senior Software Engineer - Platform Enablement
Red Hat, Inc.