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

[Eric Blake]

On Thu, Jul 29, 2021 at 11:23:16AM +0200, Corinna Vinschen wrote:
> > > > > > > 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.

Correct.

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

Those ideas seem viable.

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

Either late 2022 (I like 202212 more than 202201) as our target goal,
to minimize the number of times we have to bump it, or the date of the
current draft (202105) are the two dates I'm happiest with.  But in
practice, NO portable app should depend on the date we pick, only that
they are requesting a date newer than 200809.  Once Issue 8 is out, we
adjust our header to match the actual date, and portable code will
compare to the actual date, not our interim picks.

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

That also sounds like a good path forward to me.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org