From: Joel Sherrill <joel@rtems.org>
To: C Howland <cc1964t@gmail.com>
Cc: Newlib <newlib@sourceware.org>
Subject: Re: Fw: [PATCH 1/1] libc: Added implementations and prototypes for
Date: Wed, 28 Jul 2021 15:13:33 -0500 [thread overview]
Message-ID: <CAF9ehCUVctPJkDfeQeknTtOGX4mJESxpMaRjTe+hVAseSfxH6Q@mail.gmail.com> (raw)
In-Reply-To: <CANk6obRmSxKa4Bjdi-M1dvoZid3sOOD5Yt1C4KP3iY9GU+QTHg@mail.gmail.com>
On Wed, Jul 28, 2021, 2:54 PM C Howland <cc1964t@gmail.com> wrote:
> >
> > ------------------------------
> > *From:* Newlib <newlib-bounces+craig.howland=caci.com@sourceware.org> on
> > behalf of Joel Sherrill <joel@rtems.org>
> > *Sent:* Wednesday, July 28, 2021 3:42 PM
> > *To:* Newlib <newlib@sourceware.org>; Brian Inglis <
> > Brian.Inglis@systematicsw.ab.ca>
> > *Subject:* Re: [PATCH 1/1] libc: Added implementations and prototypes for
> >
> >
> > On Wed, Jul 28, 2021 at 1:46 PM Corinna Vinschen <vinschen@redhat.com>
> > 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
> > >
> >
> >
>
next prev parent reply other threads:[~2021-07-28 20:13 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-24 8:37 [PATCH 0/1] V2 Implementation of sig2str/str2sig Matt Joyce
2021-07-24 8:37 ` [PATCH 1/1] libc: Added implementations and prototypes for Matt Joyce
2021-07-28 9:11 ` Corinna Vinschen
2021-07-28 15:25 ` Brian Inglis
2021-07-28 18:46 ` Corinna Vinschen
2021-07-28 19:42 ` Joel Sherrill
[not found] ` <DM3P110MB0522CE441CAB289B69DE18B49AEA9@DM3P110MB0522.NAMP110.PROD.OUTLOOK.COM>
2021-07-28 19:54 ` Fw: " C Howland
2021-07-28 20:13 ` Joel Sherrill [this message]
2021-07-29 9:23 ` Corinna Vinschen
2021-07-29 14:45 ` Eric Blake
2021-07-29 15:29 ` Brian Inglis
2021-07-29 15:29 ` Brian Inglis
2021-07-29 15:45 ` Corinna Vinschen
2021-07-29 2:51 ` Brian Inglis
2021-07-28 18:40 ` Corinna Vinschen
2021-07-29 4:59 ` Matthew Joyce
2021-07-29 9:27 ` Corinna Vinschen
2021-07-29 14:41 ` Eric Blake
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAF9ehCUVctPJkDfeQeknTtOGX4mJESxpMaRjTe+hVAseSfxH6Q@mail.gmail.com \
--to=joel@rtems.org \
--cc=cc1964t@gmail.com \
--cc=newlib@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).