Fw: [PATCH 1/1] libc: Added implementations and prototypes for

Corinna Vinschen vinschen@redhat.com
Thu Jul 29 09:23:16 GMT 2021


On Jul 28 15:13, Joel Sherrill wrote:
> On Wed, Jul 28, 2021, 2:54 PM C Howland wrote:
> > > On Wed, Jul 28, 2021 at 1:46 PM Corinna Vinschen wrote:
> > > > On Jul 28 09:25, Brian Inglis wrote:
> > > > > On 2021-07-28 03:11, Corinna Vinschen wrote:
> > > > > > On Jul 24 10:37, Matt Joyce wrote:
> > > > > > > +#if __GNU_VISIBLE
> > > > > >
> > > > > > I think this needs discussion.  The sig2str/str2sig API has not
> > been
> > > > > > provided yet by GLibC.  Using __GNU_VISIBLE in this context looks
> > > wrong.
> > > > > > What we need, in fact, is a __POSIX_VISIBLE guard, but here's the
> > > > > > problem: As far as I can see, the Issue 8 draft does not yet
> > define a
> > > > > > version number.
> > > > > >
> > > > > > If anybody has better information or a good idea how to guard this
> > > new
> > > > > > API in the meantime, I'm all ears.
> > > > >
> > > > > Current values are:
> > > > >
> > > > > __POSIX_VISIBLE 199009
> > > > > __POSIX_VISIBLE 199209
> > > > > __POSIX_VISIBLE 199309
> > > > > __POSIX_VISIBLE 199506
> > > > > __POSIX_VISIBLE 200112
> > > > > __POSIX_VISIBLE 200809
> > > > > __POSIX_VISIBLE 201402

Where did you find the latter one?  Per the Open Group docs
https://pubs.opengroup.org/onlinepubs/9699919799/ the latest valid value
for _POSIX_C_SOURCE is still 200809, even with POSIX.1-2017.

> > > > > so could use:
> > > > >
> > > > > __POSIX_VISIBLE >= 202202 /* FIXME when POSIX Issue 8 released */
> > > > [...]
> > It really does not matter a whole lot.  The gates are only on the function
> > prototypes in the header file.  It could just use the date of when the file
> > is added for the time being, really.
> 
> This isn't a bad idea.
> 
> And similarly we could use May 2021 which is the date on Issue 8 Draft 2.
> 
> To be more gung-ho, something like
> > #define POSIX8_RELDATE 202202 // FIXME WHEN REAL RELEASE DATE KNOWN
> > could be added to sys/features.h, and then this file could use that.
> > features.h will have to be edited when the new POSIX comes out, so just
> > place it appropriately to make the need to change it obvious.
> >
> 
> I'm for this and use 202105. If a new draft comes out, maybe we bump it.
> 
> Good thoughts Craig!

Indeed.  However, I discussed this with Florian Weimer (added to CC)
from the GLibc team.  The conclusion was:

- The API is already defined in Solaris:
  https://docs.oracle.com/cd/E86824_01/html/E54766/str2sig-3c.html
  Therefore GLibC will use __USE_MISC (equivalent to our __MISC_VISIBLE)
  as feature test macro.

- As soon as POSIX Issue 8 has an identifier, it will be added to
  the feature test, i. e., something like

    if defined(__USE_MISC) || defined(__USE_POSIX123456)

Ideally we should do the same.  So for the time being, let's use

  #if __MISC_VISIBLE

as feature test and add the matching __POSIX_VISIBLE test as soon as the
issue 8 value has been published.

Is that ok with everyone?


Thanks,
Corinna



More information about the Newlib mailing list