* APIs in New POSIX Edition @ 2021-04-07 23:26 Joel Sherrill 2021-04-08 11:18 ` Corinna Vinschen 0 siblings, 1 reply; 7+ messages in thread From: Joel Sherrill @ 2021-04-07 23:26 UTC (permalink / raw) To: Newlib 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: APIs in New POSIX Edition 2021-04-07 23:26 APIs in New POSIX Edition Joel Sherrill @ 2021-04-08 11:18 ` Corinna Vinschen 2021-04-08 11:38 ` Joel Sherrill 0 siblings, 1 reply; 7+ messages in thread From: Corinna Vinschen @ 2021-04-08 11:18 UTC (permalink / raw) To: newlib 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: APIs in New POSIX Edition 2021-04-08 11:18 ` Corinna Vinschen @ 2021-04-08 11:38 ` Joel Sherrill 2021-04-08 11:49 ` Corinna Vinschen 0 siblings, 1 reply; 7+ messages in thread From: Joel Sherrill @ 2021-04-08 11:38 UTC (permalink / raw) To: Newlib 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 > > ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: APIs in New POSIX Edition 2021-04-08 11:38 ` Joel Sherrill @ 2021-04-08 11:49 ` Corinna Vinschen 2021-04-08 11:56 ` Corinna Vinschen 2021-04-09 17:55 ` Yaakov Selkowitz 0 siblings, 2 replies; 7+ messages in thread From: Corinna Vinschen @ 2021-04-08 11:49 UTC (permalink / raw) To: newlib 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: APIs in New POSIX Edition 2021-04-08 11:49 ` Corinna Vinschen @ 2021-04-08 11:56 ` Corinna Vinschen 2021-04-08 12:07 ` Corinna Vinschen 2021-04-09 17:55 ` Yaakov Selkowitz 1 sibling, 1 reply; 7+ messages in thread From: Corinna Vinschen @ 2021-04-08 11:56 UTC (permalink / raw) To: newlib 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: APIs in New POSIX Edition 2021-04-08 11:56 ` Corinna Vinschen @ 2021-04-08 12:07 ` Corinna Vinschen 0 siblings, 0 replies; 7+ messages in thread From: Corinna Vinschen @ 2021-04-08 12:07 UTC (permalink / raw) To: newlib 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: APIs in New POSIX Edition 2021-04-08 11:49 ` Corinna Vinschen 2021-04-08 11:56 ` Corinna Vinschen @ 2021-04-09 17:55 ` Yaakov Selkowitz 1 sibling, 0 replies; 7+ messages in thread From: Yaakov Selkowitz @ 2021-04-09 17:55 UTC (permalink / raw) To: newlib 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2021-04-09 17:55 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-04-07 23:26 APIs in New POSIX Edition Joel Sherrill 2021-04-08 11:18 ` Corinna Vinschen 2021-04-08 11:38 ` Joel Sherrill 2021-04-08 11:49 ` Corinna Vinschen 2021-04-08 11:56 ` Corinna Vinschen 2021-04-08 12:07 ` Corinna Vinschen 2021-04-09 17:55 ` Yaakov Selkowitz
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).