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

On Wed, Jul 28, 2021, 2:54 PM C Howland <[email protected]> wrote:

> >
> > ------------------------------
> > *From:* Newlib <[email protected]> on
> > behalf of Joel Sherrill <[email protected]>
> > *Sent:* Wednesday, July 28, 2021 3:42 PM
> > *To:* Newlib <[email protected]>; Brian Inglis <
> > [email protected]>
> > *Subject:* Re: [PATCH 1/1] libc: Added implementations and prototypes for
> >
> >
> > On Wed, Jul 28, 2021 at 1:46 PM Corinna Vinschen <[email protected]>
> > wrote:
> > >
> > > On Jul 28 09:25, Brian Inglis wrote:
> > > > On 2021-07-28 03:11, Corinna Vinschen wrote:
> > > > > Hi Matt,
> > > > >
> > > > > thanks for this v2.
> > > > >
> > > > > On Jul 24 10:37, Matt Joyce wrote:
> > > > > > Added implementations for sig2str() and str2sig() in libc/signal
> > in order
> > > > > > to improve POSIX compliance. Added function prototypes to
> > sys/signal.h.
> > > > > > Added Makefile.am entries to build the new file.
> > > > > > ---
> > > > > > [...]
> > > > > > +#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
> > > >
> > > > and anticipated release date is 2022 from FAQ
> > > >
> > > >       https://www.opengroup.org/austin/faq.html
> > > >
> > > >       Q8. Where is the schedule for draft development?
> > > >
> > > > so could use:
> > > >
> > > > __POSIX_VISIBLE >= 202202 /* FIXME when POSIX Issue 8 released */
> > >
> > > Did you mean 202201?  Sounds like a good idea in theory.  But consider
> a
> > > project actually using this value and then the POSIX release defines
> the
> > > value 202207 or so.  The project might stop to compile correctly.
> Along
> > > these lines, using 202212 for the interim might be the better approach.
> > > Then again, what if the release occurs in 2023 only?
> > >
> > > Still pretty unsure,
> >
> > Me too.  I told Matthew early on that the header guard for this was going
> > to require discussion because I had no idea what was right.
> >
> > It would be nice to have this available on multiple platforms. Would it
> be
> > acceptable to make the header conditional on Cygwin and RTEMS for now?
> > Can we conditionalize the C file for just those two?
> >
> 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!

--joel

Craig
>
> >
> > Does newlib have a ticketing/PR system? If so, we could revisit this when
> > Issue 8 is released. Alternatively, we can file a ticket in Cygwin and
> > RTEMS
> > and see which one of us remembers it first after Issue 8 is out. I know
> if
> > we
> > tag a ticket with the next release, it should get reviewed as we start
> > cleaning
> > up as the code gets slushier.
> >
> > --joel
> >
> > > Corinna
> > >
> >
> >
>