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

[Adhemerval Zanella]

On 14/05/2020 13:40, Florian Weimer wrote:
> * 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.
> 
> But dropping features from existing interfaces does not seem a good
> alternative in this case.
> 
>>> 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?
> 
> No, the libc-internal equivalent of pthread_key_create
> (__libc_key_create).

Right, it seems that dlfcn is the only place that still uses it.

What about moving per-thread state to __thread (generic) / pthread (Linux),
do you have some reservation about it?

> 
>>> 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?
> 
> First hit from the Debian Code Search query I posted:
> 
> 		die(_("cannot open %s: %s"), device_name, strerror(errno));
> 
> Currently, this translates to:
> 
>   DEVICE_NAME kann nicht geöffnet werden: Datei oder Verzeichnis nicht gefunden
> 
> After removing translation from strerror, this turns into:
> 
>   DEVICE_NAME kann nicht geöffnet werden: No such file or directory
> 
> That's a clear regression.

Alright, as from Zack message I took this semantic change would to make them 
async-signal-safe allow to be more beneficial in the long term (in both code 
complexity and more concise API) but looks like we should go to newer symbols 
instead.