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