[PATCH 0/1] V2 Implementation of sig2str/str2sig

[PATCH 0/1] V2 Implementation of sig2str/str2sig

[Matt Joyce]

Dear Newlib Maintainers,

I have updated the following on my initial patch:

1) Added Makefile entries to build new file
2) Edited definition of SIG2STR_MAX as discussed
3) Added code for "RTMAX-m" in sig2str
4) Added check for whether RTMIN==RTMAX
5) Removed <signum> from "Unknown signal" error message. I reasoned
that this would be ok because the standard does not mention any
error message anyway and it could potentially avoid problems with
the length of the string representation of the invalid signum
exceeding the length of the SIG2STR_MAX sized buffer.

Standing by for any further feedback. Thank you very much for your
time!

Matt Joyce (1):
  libc: Added implementations and prototypes for sig2str/str2sig methods

 newlib/libc/include/sys/signal.h |  16 ++
 newlib/libc/signal/Makefile.am   |   4 +-
 newlib/libc/signal/sig2str.c     | 257 +++++++++++++++++++++++++++++++
 3 files changed, 275 insertions(+), 2 deletions(-)
 create mode 100644 newlib/libc/signal/sig2str.c

-- 
2.31.1

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

[Matt Joyce]

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.
---
 newlib/libc/include/sys/signal.h |  16 ++
 newlib/libc/signal/Makefile.am   |   4 +-
 newlib/libc/signal/sig2str.c     | 257 +++++++++++++++++++++++++++++++
 3 files changed, 275 insertions(+), 2 deletions(-)
 create mode 100644 newlib/libc/signal/sig2str.c

diff --git a/newlib/libc/include/sys/signal.h b/newlib/libc/include/sys/signal.h
index 45cc0366c..e249e7040 100644
--- a/newlib/libc/include/sys/signal.h
+++ b/newlib/libc/include/sys/signal.h
@@ -12,6 +12,7 @@ extern "C" {
 #include <sys/types.h>
 #include <sys/_sigset.h>
 #include <sys/_timespec.h>
+#include <stdint.h>
 
 #if !defined(_SIGSET_T_DECLARED)
 #define	_SIGSET_T_DECLARED
@@ -238,6 +239,21 @@ int sigqueue (pid_t, int, const union sigval);
 
 #endif /* __POSIX_VISIBLE >= 199309 */
 
+#if __GNU_VISIBLE
+
+/* POSIX Issue 8 adds sig2str() and str2sig(). */
+
+#if __STDINT_EXP(INT_MAX) > 0x7fff
+#define SIG2STR_MAX (sizeof("RTMAX+") + sizeof("4294967295") - 1)
+#else
+#define SIG2STR_MAX (sizeof("RTMAX") + sizeof("65535") - 1)
+#endif 
+
+int sig2str(int, char *);
+int str2sig(const char *__restrict, int *__restrict);
+
+#endif /* __GNU_VISIBLE */
+
 #if defined(___AM29K__)
 /* These all need to be defined for ANSI C, but I don't think they are
    meaningful.  */
diff --git a/newlib/libc/signal/Makefile.am b/newlib/libc/signal/Makefile.am
index a93dba7a9..89db26113 100644
--- a/newlib/libc/signal/Makefile.am
+++ b/newlib/libc/signal/Makefile.am
@@ -4,7 +4,7 @@ AUTOMAKE_OPTIONS = cygnus
 
 INCLUDES = $(NEWLIB_CFLAGS) $(CROSS_CFLAGS) $(TARGET_CFLAGS)
 
-LIB_SOURCES = psignal.c raise.c signal.c
+LIB_SOURCES = psignal.c raise.c signal.c sig2str.c
 
 libsignal_la_LDFLAGS = -Xcompiler -nostdlib
 
@@ -21,6 +21,6 @@ endif # USE_LIBTOOL
 
 include $(srcdir)/../../Makefile.shared
 
-CHEWOUT_FILES = psignal.def raise.def signal.def
+CHEWOUT_FILES = psignal.def raise.def signal.def sig2str.def
 
 CHAPTERS = signal.tex
diff --git a/newlib/libc/signal/sig2str.c b/newlib/libc/signal/sig2str.c
new file mode 100644
index 000000000..2ce0049b7
--- /dev/null
+++ b/newlib/libc/signal/sig2str.c
@@ -0,0 +1,257 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+/*
+ * Copyright (C) 2021 Matthew Joyce
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *    notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *    notice, this list of conditions and the following disclaimer in the
+ *    documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/* Defining _GNU_SOURCE to have access to SIG2STR_MAX in signal.h. */
+#define _GNU_SOURCE 
+#include <signal.h>
+#include <string.h>
+#include <stdio.h>
+#include <stdlib.h>
+
+#define SPACES_TO_N 6 /* Allows indexing to RT Signal number in str2sig */
+#define NUM_OF_SIGS (sizeof(sig_array) / sizeof(sig_name_and_num))
+
+typedef struct sig_name_and_num {
+  const char *sig_name;
+  const int  sig_num; 
+} sig_name_and_num;
+
+static const sig_name_and_num sig_array[] = {
+    #ifdef SIGHUP
+      { "HUP", SIGHUP},
+    #endif
+    #ifdef SIGINT
+      { "INT", SIGINT },
+    #endif
+    #ifdef SIGQUIT
+      { "QUIT", SIGQUIT },
+    #endif
+    #ifdef SIGILL
+      { "ILL", SIGILL },
+    #endif
+    #ifdef SIGTRAP
+      { "TRAP", SIGTRAP },
+    #endif
+    #ifdef SIGABRT
+      { "ABRT", SIGABRT },
+    #endif
+    #ifdef SIGIOT
+      { "IOT", SIGIOT},
+    #endif
+    #ifdef SIGEMT
+      { "EMT", SIGEMT },
+    #endif
+    #ifdef SIGFPE
+      { "FPE", SIGFPE },
+    #endif
+    #ifdef SIGKILL
+      { "KILL", SIGKILL },
+    #endif
+    #ifdef SIGBUS
+      { "BUS", SIGBUS },
+    #endif
+    #ifdef SIGSEGV
+      { "SEGV", SIGSEGV },
+    #endif
+    #ifdef SIGSYS
+      { "SYS", SIGSYS },
+    #endif
+    #ifdef SIGPIPE
+      { "PIPE", SIGPIPE },
+    #endif
+    #ifdef SIGALRM
+      { "ALRM", SIGALRM },
+    #endif
+    #ifdef SIGTERM
+      { "TERM", SIGTERM },
+    #endif
+    #ifdef SIGURG
+      { "URG", SIGURG },
+    #endif
+    #ifdef SIGSTOP
+      { "STOP", SIGSTOP },
+    #endif
+    #ifdef SIGTSTP
+      { "TSTP", SIGTSTP },
+    #endif
+    #ifdef SIGCONT
+      { "CONT", SIGCONT },
+    #endif
+    #ifdef SIGCHLD
+      { "CHLD", SIGCHLD },
+    #endif
+    #ifdef SIGCLD
+      { "CLD", SIGCLD },
+    #endif
+    #ifdef SIGTTIN
+      { "TTIN", SIGTTIN },
+    #endif
+    #ifdef SIGTTOU
+      { "TTOU", SIGTTOU },
+    #endif
+    #ifdef SIGIO
+      { "IO", SIGIO },
+    #endif
+    #ifdef SIGPOLL
+      { "POLL", SIGPOLL },
+    #endif
+    #ifdef SIGWINCH
+      { "WINCH", SIGWINCH },
+    #endif
+    #ifdef SIGUSR1
+      { "USR1", SIGUSR1 },
+    #endif
+    #ifdef SIGUSR2
+      { "USR2", SIGUSR2 },
+    #endif
+    #ifdef SIGPWR
+      { "PWR", SIGPWR },
+    #endif
+    #ifdef SIGXCPU
+      { "XCPU", SIGXCPU },
+    #endif
+    #ifdef SIGXFSZ
+      { "XFSZ", SIGXFSZ },
+    #endif
+    #ifdef SIGVTALRM
+      { "VTALRM", SIGVTALRM },
+    #endif
+    #ifdef SIGPROF
+      { "PROF", SIGPROF },
+    #endif
+    #ifdef SIGLOST
+      { "LOST", SIGLOST },
+    #endif
+    /* The Issue 8 standard requires that SIGRTMIN and SIGRTMAX be included 
+     * as valid results to be saved from calls to sig2str/str2sig.  */
+    #ifdef SIGRTMIN
+      { "RTMIN", SIGRTMIN },
+    #endif
+    #ifdef SIGRTMAX
+      { "RTMAX", SIGRTMAX }
+    #endif
+}; 
+
+int
+sig2str(int signum, char *str)
+{
+  const sig_name_and_num *sptr;
+
+  /* If signum falls in lower half of the real time signals range, define
+   * the saved str value as "RTMIN+n" according to the Issue 8 standard */
+  if ((SIGRTMIN + 1) <= signum && 
+      signum <= (SIGRTMIN + SIGRTMAX) / 2) {
+    sprintf(str, "RTMIN+%d", (signum-SIGRTMIN));
+    return 0; 
+  }
+  
+  /* If signum falls in upper half of the real time signals range, define
+   * the saved str value as "RTMAX-m" according to the Issue 8 standard */
+  if ((((SIGRTMIN + SIGRTMAX) / 2) + 1) <= signum &&
+         signum <= (SIGRTMAX - 1)) {
+    sprintf(str, "RTMAX-%d", (SIGRTMAX - signum));
+    return 0; 
+  }
+
+  /* Otherwise, search for signal matching signum in sig_array. If found,
+   * save its string value in str. */ 
+  for (sptr = sig_array; sptr < &sig_array[NUM_OF_SIGS]; sptr++) {
+    if (sptr->sig_num == signum) {
+      strcpy(str, sptr->sig_name);
+      return 0; 
+    } 
+  }   
+
+  /* If signum is not a recognized signal number, store this message in str. */
+  sprintf(str, "Unknown signal"); 
+  return -1; 
+}
+
+int
+str2sig(const char *restrict str, int *restrict pnum)
+{
+  unsigned long j = 0; 
+  char *endp; 
+  const sig_name_and_num *sptr; 
+  int is_valid_decimal;
+  is_valid_decimal = atoi(str);
+
+  /* If str is a representation of a decimal value, save its integer value
+   * in pnum. */
+  if (1 <= is_valid_decimal &&
+      is_valid_decimal <= SIGRTMAX) {
+    *pnum = is_valid_decimal; 
+    return 0; 
+  }
+
+  /* i686 Cygwin only supports one RT signal. For this case, skip checks 
+   * for "RTMIN+n" and "RTMAX-m". */
+  if (SIGRTMIN != SIGRTMAX) {
+
+    /* If str is in RT signal range, get number of of RT signal, save it as an 
+    * integer. */
+    if (strncmp(str, "RTMIN+", SPACES_TO_N) == 0) {
+      j = strtoul(&str[SPACES_TO_N], &endp, 10); 
+
+      /* If number is valid, save it in pnum. */
+      if (*endp == '\0') {
+        if (1 <= j &&
+            j <= ((SIGRTMAX - SIGRTMIN)-1)) {
+          *pnum = (SIGRTMIN + j);
+          return 0;
+        }
+        return -1; 
+      }
+      return -1;
+    }
+    
+    /* If str is in RT signal range, get number of of RT signal, save it as an 
+    * integer. */
+    if (strncmp(str, "RTMAX-", SPACES_TO_N) == 0) {
+      j = strtoul(&str[SPACES_TO_N], &endp, 10); // and endptr null check
+
+      /* If number is valid, save it in pnum. */
+      if (*endp == '\0') {
+        if (1 <= j &&
+            j <= ((SIGRTMAX - SIGRTMIN)-1)) {
+          *pnum = (SIGRTMAX - j);
+          return 0;
+        }
+        return -1; 
+      }
+      return -1;
+    }
+  }
+
+  /*If str is a valid signal name, save its corresponding number in pnum. */
+  for (sptr = sig_array; sptr < &sig_array[NUM_OF_SIGS]; sptr++) {
+    if (strcmp(sptr->sig_name, str) == 0) {
+      *pnum = sptr->sig_num;
+      return 0; 
+    }    
+  }
+  return -1; 
+}
-- 
2.31.1

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

[Corinna Vinschen]

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.

>  
>  include $(srcdir)/../../Makefile.shared
>  
> -CHEWOUT_FILES = psignal.def raise.def signal.def
> +CHEWOUT_FILES = psignal.def raise.def signal.def sig2str.def

If you add this, you also have to provide a header allowing to create
a man page.  See, for instance, newlib/signal/raise.c.

> +int
> +sig2str(int signum, char *str)
> [...]
> +  /* If signum is not a recognized signal number, store this message in str. */
> +  sprintf(str, "Unknown signal"); 

Just drop this sprintf, as I just wrote in my other mail.  There's no
expectation that the incoming buffer gets changed if the function
returns with error.

> +  return -1; 
> +}
> +
> +int
> +str2sig(const char *restrict str, int *restrict pnum)
> +{
> +  unsigned long j = 0; 
> +  char *endp; 
> +  const sig_name_and_num *sptr; 
> +  int is_valid_decimal;
> +  is_valid_decimal = atoi(str);

What if the input is "12xyz"?  This, too, needs checking with strtoul.

The rest looks good to me.


Thanks,
Corinna

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

[Brian Inglis]

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 */

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]

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

[Corinna Vinschen]

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,
Corinna

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

[Joel Sherrill]

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?

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
>

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

[C Howland]

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

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

[Joel Sherrill]

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

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

[Corinna Vinschen]

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

Re: 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

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

[Brian Inglis]

On 2021-07-29 03:23, Corinna Vinschen wrote:
> 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

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

Searched all installed include files for all __POSIX_VISIBLE date 
expressions [Paste As Quotation avoids wrapping commands and output]:

> $ grep '__POSIX_VISIBLE.*[12][90][0-9][0-9][01][0-9]' /usr/{,*86*/sys-root/*/}include/**/*.h

To answer your question:

 > $ grep '__POSIX_VISIBLE.*2014' /usr/{,*86*/sys-root/*/}include/**/*.h
> /usr/include/pthread.h:#if __XSI_VISIBLE >= 500 || __POSIX_VISIBLE >= 200112 || __cplusplus >= 201402L

I used sed to extract and standardize so I could sort -u to get the 
list, which I saved and added a few comments to:

> /* POSIX-version-dates.h - POSIX dates found in headers and related standards */
> 
> #define	__POSIX_VISIBLE 199009	/* Issue 1 */
> #define	__POSIX_VISIBLE 199209	/* Issue 2 */
> #define	__POSIX_VISIBLE 199309	/* Issue 3 UNIX 93 */
> #define	__POSIX_VISIBLE 199506	/* Issue 4 SUS V1 UNIX 95 XPG4 COSE Spec 1170 */
> #define	__POSIX_VISIBLE 200112	/* Issue 5 SUS V3 UNIX 03 */
> #define	__POSIX_VISIBLE 200809	/* Issue 6 SUS V4 */
> #define	__POSIX_VISIBLE 201402	/* Issue 7 SUS V4 TC1 UNIX V7 */
> #define	__POSIX_VISIBLE 202202?	/* Issue 8 SUS V5? UNIX V8? */

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]

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

[Brian Inglis]

On 2021-07-29 03:23, Corinna Vinschen wrote:
> 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

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

Searched all installed include files for all __POSIX_VISIBLE date 
expressions [Paste As Quotation avoids wrapping commands and output]:

> $ grep '__POSIX_VISIBLE.*[12][90][0-9][0-9][01][0-9]' /usr/{,*86*/sys-root/*/}include/**/*.h

To answer your question:

 > $ grep '__POSIX_VISIBLE.*2014' /usr/{,*86*/sys-root/*/}include/**/*.h
> /usr/include/pthread.h:#if __XSI_VISIBLE >= 500 || __POSIX_VISIBLE >= 200112 || __cplusplus >= 201402L

I used sed to extract and standardize so I could sort -u to get the 
list, which I saved and added a few comments to:

> /* POSIX-version-dates.h - POSIX dates found in headers and related standards */
> 
> #define	__POSIX_VISIBLE 199009	/* Issue 1 */
> #define	__POSIX_VISIBLE 199209	/* Issue 2 */
> #define	__POSIX_VISIBLE 199309	/* Issue 3 UNIX 93 */
> #define	__POSIX_VISIBLE 199506	/* Issue 4 SUS V1 UNIX 95 XPG4 COSE Spec 1170 */
> #define	__POSIX_VISIBLE 200112	/* Issue 5 SUS V3 UNIX 03 */
> #define	__POSIX_VISIBLE 200809	/* Issue 6 SUS V4 */
> #define	__POSIX_VISIBLE 201402	/* Issue 7 SUS V4 TC1 UNIX V7 */
> #define	__POSIX_VISIBLE 202202?	/* Issue 8 SUS V5? UNIX V8? */

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]

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

[Corinna Vinschen]

On Jul 29 09:29, Brian Inglis wrote:
> On 2021-07-29 03:23, Corinna Vinschen wrote:
> > 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
> 
> > > > > > > > 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.
> 
> Searched all installed include files for all __POSIX_VISIBLE date
> expressions [Paste As Quotation avoids wrapping commands and output]:
> 
> > $ grep '__POSIX_VISIBLE.*[12][90][0-9][0-9][01][0-9]' /usr/{,*86*/sys-root/*/}include/**/*.h
> 
> To answer your question:
> 
> > $ grep '__POSIX_VISIBLE.*2014' /usr/{,*86*/sys-root/*/}include/**/*.h
> > /usr/include/pthread.h:#if __XSI_VISIBLE >= 500 || __POSIX_VISIBLE >= 200112 || __cplusplus >= 201402L

Ok, but that's the version number for C++14 then...


Corinna

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

[Brian Inglis]

On 2021-07-28 12:46, Corinna Vinschen 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?

Best guess of earliest release (V8 exactly 8 years after V7 - spooky!)
Jan too early in year for consensus agreement and release process.
Actual value could be later if defined (if so likely 202209 from history 
- couple months after NA vacation period) so will still test true.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]

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

[Corinna Vinschen]

On Jul 28 11: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.
> 
> >  
> >  include $(srcdir)/../../Makefile.shared
> >  
> > -CHEWOUT_FILES = psignal.def raise.def signal.def
> > +CHEWOUT_FILES = psignal.def raise.def signal.def sig2str.def
> 
> If you add this, you also have to provide a header allowing to create
> a man page.  See, for instance, newlib/signal/raise.c.
> 
> > +int
> > +sig2str(int signum, char *str)
> > [...]
> > +  /* If signum is not a recognized signal number, store this message in str. */
> > +  sprintf(str, "Unknown signal"); 
> 
> Just drop this sprintf, as I just wrote in my other mail.  There's no
> expectation that the incoming buffer gets changed if the function
> returns with error.

Additionally, there's a RATIONALE section in the draft, which describes
how "historical versions of these functions translated a signum value 0
to "EXIT" (and vice versa), so that they could be used by the shell for
the trap utility."

While this isn't going to become part of the standard, I wonder if we
should follow suite, for maximum compatibility.


Corinna

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

[Matthew Joyce]

Hi Corinna,

Thank you again for the feedback! I'll make the changes as you
recommend. Two things to note:

1) Regarding the header guard, I'm also all ears! Joel was also
concerned about this but ultimately recommended __GNU_VISIBLE for now,
while there is still no version number. I'll stand by if there are any
alternative suggestions on this.

2) "EXIT": As a beginner, obviously please take what I say with
several grains of salt! My rationale for not including 0 / EXIT was
line 61853 where it states "if signum is equal to 0, the behavior is
unspecified", and the end of the RATIONALE section where it says "the
behavior in this case has been made unspecified." I'd think if we
added in EXIT / 0, we'd be going against those statements.

Thanks again!

Sincerely,

Matt


On Wed, Jul 28, 2021 at 8:40 PM Corinna Vinschen <vinschen@redhat.com> wrote:
>
> On Jul 28 11: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.
> >
> > >
> > >  include $(srcdir)/../../Makefile.shared
> > >
> > > -CHEWOUT_FILES = psignal.def raise.def signal.def
> > > +CHEWOUT_FILES = psignal.def raise.def signal.def sig2str.def
> >
> > If you add this, you also have to provide a header allowing to create
> > a man page.  See, for instance, newlib/signal/raise.c.
> >
> > > +int
> > > +sig2str(int signum, char *str)
> > > [...]
> > > +  /* If signum is not a recognized signal number, store this message in str. */
> > > +  sprintf(str, "Unknown signal");
> >
> > Just drop this sprintf, as I just wrote in my other mail.  There's no
> > expectation that the incoming buffer gets changed if the function
> > returns with error.
>
> Additionally, there's a RATIONALE section in the draft, which describes
> how "historical versions of these functions translated a signum value 0
> to "EXIT" (and vice versa), so that they could be used by the shell for
> the trap utility."
>
> While this isn't going to become part of the standard, I wonder if we
> should follow suite, for maximum compatibility.
>
>
> Corinna
>

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

[Corinna Vinschen]

Hi Matt,

On Jul 29 06:59, Matthew Joyce wrote:
> Hi Corinna,
> 
> Thank you again for the feedback! I'll make the changes as you
> recommend. Two things to note:
> 
> 1) Regarding the header guard, I'm also all ears! Joel was also
> concerned about this but ultimately recommended __GNU_VISIBLE for now,
> while there is still no version number. I'll stand by if there are any
> alternative suggestions on this.

In other mail.

> 2) "EXIT": As a beginner, obviously please take what I say with
> several grains of salt! My rationale for not including 0 / EXIT was
> line 61853 where it states "if signum is equal to 0, the behavior is
> unspecified", and the end of the RATIONALE section where it says "the
> behavior in this case has been made unspecified." I'd think if we
> added in EXIT / 0, we'd be going against those statements.

The problem is that we have prior art here.  Solaris as well as Gnulib
are generating this value.  Even if it's not part of the standard, it
makes sense to follow other, already existing implementations, to ease
the pain of porting.


Corinna

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

[Eric Blake]

On Wed, Jul 28, 2021 at 11:11:04AM +0200, 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.

Correct.  As of draft 2 (May 2021), the text of XSH 2.2.1P8 has been
amended to read:

  For the C programming language, shall define _POSIX_C_SOURCE to be 20yymmL |
  before any header is included

The goal is that draft 3 will be the first draft of Issue 8 that
finishes the intended update of POSIX from C99 (the base standard used
in Issue 7, and in the 2017 document) to C17, and as part of that
update, it will align any new macros, interfaces, and so forth
required by the move to the newer C standard.  The current status
reports say draft 3 may come as soon as Q3 of 2021
(https://www.opengroup.org/austin/docs/austin_1148.txt), but September
is coming up pretty fast.  The actual date chosen for _POSIX_C_SOURCE
will probably be picked to align with when Issue 8 is completed, which
will not be any sooner than late 2022.

> 
> If anybody has better information or a good idea how to guard this new
> API in the meantime, I'm all ears.

I think as long as we pick an arbitrary date in the future, then
refine it to the actual date once one is known, we're probably okay.
No portable code should care what date we picked in the short term
(code portable to Issue 8 will pick the final date, and in the
meantime, code trying to comply to Issue 8 is already non-portable
since Issue 8 is still in flux).

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