[PATCH 2/5] signal: Move sys_siglist to a compat symbol

[Florian Weimer]

* Adhemerval Zanella:

> On 29/04/2020 08:57, Florian Weimer wrote:
>> * Adhemerval Zanella:
>> 
>>>>> And even its usage is not fully portable (solaris11 defines as
>>>>> _sys_siglist, AIX 73 does not provide it). So I am not sure if we
>>>>> should continue provide for newly binaries.
>>>>
>>>> Another difference is that the variables are async-signal-safe.
>>>> strerror and strsignal might not be if the argument is out of range
>>>> (something that can be checked with the count variable in the other
>>>> case).  At least our strsignal is already thread-safe.
>>>>
>>>
>>> We have strerror_r at least as an extension.
>> 
>> It's not an extension, but GNU has a different prototype.  This makes
>> this interface really hard to use unfortunately.  Hence my desire for
>> a thread-safe strerror (which everyone assumes anyway).
>
> Indeed, but I think this is a different issue.  We have:
>
> strerror           MT-unsafe   AS-Unsafe 
> strerror_r (XSI)   MT-safe     AS-unsafe
> strerror_r (GNU)   MT-safe     AS-unsafe
> strerror_l         MT-safe     AS-unsafe
>
> And I think we should do:
>
> strerror           MT-unsafe   AS-safe 
> strerror_r (XSI)   MT-safe     AS-safe
> strerror_r (GNU)   MT-safe     AS-safe
> strerror_l         MT-safe     AS-unsafe
>
> By making strerror_r (which is used by both strerror and __xpg_strerror_r)
> no translate the error messages.

I think that's even more confusing than before because of the
different results between strerror, strerror_r, and strerror_l under
the same effective locale.

I have a proposal that will allow us to make strerror thread-safe:

  <http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2444.htm>

Then we can just forget about strerror_r.

> As for strsignal, it would be trickier because it uses the allocated
> buffer with __libc_once which might trigger malloc.  Maybe an option 
> might to just follow the strerror and also provide a thread safe 
> variant.  From:
>
> strsignal          MT-safe     AS-unsafe
>
> To:
>
> strsignal          MT-unsafe   AS-safe
> strsignal_r        MT-safe     AS-safe
> strsignal_l        MT-safe     AS-unsafe
>
> By also making strsignal not translate the error messages and not
> fallback to allocate the internal buffer.

Likewise, I don't think a non-thread-safe strsignal function is
useful.

The errno_constant and signal_constant functions would just provide
the names of the E* and SIG* constants, which seems more useful to me
than the different strings that implementations use even in the
English locale.