[RFC 0/4] Make strsignal and strerror async-signal-safe

[Florian Weimer]

* Adhemerval Zanella:

> On 14/05/2020 09:05, Florian Weimer wrote:
>> * Adhemerval Zanella via Libc-alpha:
>> 
>>>   2. Avoid to try translate the returned message.
>> 
>> No more translation is a significant change.  Is this really
>> appropriate?
>
> I take that once we have proper symbols that provides the translation
> functionality, making them async-signal-safe is an welcome
> improvement.

But why would non-portable software switch to those interfaces?

It seems more conservative to me to introduce new interfaces that are
async-signal-safe (and thread-safe).

This change also continues the pattern of removal of widely-used
interfaces without a deprecation warning (although these interfaces have
been informally deprecated for a long time, so maybe that's okay).

> The glibc itself uses the __sys_* access on libSegFault due this
> shortcoming.  And I am not if other programs are really aware of
> the shortcoming of the always translatable error strings.

Thread safety for strerror can be a problem.  We can fix that
independently.  Also the use of legacy TLS is problematic and we should
get rid of that.

>> Using strerror output in translated strings is very common:
>> 
>> <https://codesearch.debian.net/search?q=_%5C%28.*strerror&literal=0>
>> 
>> I still prefer my approach with new functions which return a string
>> (with the name of the constant), but only for known error numbers.  I
>> think the constant names would also be more useful to us in diagnostics.
>
> New non-standard symbols takes time and code effort to be used, and
> it would required either to be implemented in other libc to fully
> portable or even additional efforts from the projects to use it 
> (and there is recent trend to avoid use new glibc symbol that might
> break the usage on older glibc, although it is not really supported
> from out side).

Yes, but as I showed you, your proposed change leads to partially
translated strings.  I don't see a compelling reason to do that.  Yes,
intl/ is not async-signal-safe, and it would be some work to make it so,
but that isn't justification enough to drop the translation.

Thanks,
Florian