[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