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

[Adhemerval Zanella]

On 14/05/2020 12:16, Florian Weimer wrote:
> * 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).

The downside is new interface usually takes time to be adopted, they add
even more code bloat/complexity to support old interfaces, and they
does help current usage.

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

By legacy TLS do you mean __thread usage?

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

What do you mean by *partially* translated?