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

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

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.

> 
>>
>>> I'm going to propose errno_constant and signal_constant functions to
>>> cover the async-signal-safe case.  Let's see if they gain positive
>>> feedback from the larger libc community.
>>
>> Instead I think it would be better just simplify glibc strerror
>> and strsignal assumptions to *not* return locale dependent messages
>> and add a strsignal_l for the case.
>>
>> So strerror/strsignal will just directly access the underlying error
>> with the expected bound error checks and thus be asignal-safe.
> 
> There's still the formatting of unknown errors and signals.  I'm not
> sure if we want to regress there.  (Userspace can sometimes see
> invalid errors from kernel subsystems.)
> 

It would be still formatted, but the default error message won't be
translated (as for other messages). I am not sure this characterize
a hard regression if the idea is to provide async-signal-safeness.