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

[Zack Weinberg]

On Thu, May 14, 2020 at 8:47 AM Adhemerval Zanella via Libc-alpha
<libc-alpha@sourceware.org> wrote:
> 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?
> >
> > Using strerror output in translated strings is very common:
> >
> > <https://codesearch.debian.net/search?q=_%5C%28.*strerror&literal=0>
>
> I take that once we have proper symbols that provides the translation
> functionality, making them async-signal-safe is an welcome improvement.
>
> 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.

I think I'm with Florian here.  There is lots of existing code that
expects strerror() to translate, and _most_ of the time it's not being
called from an async signal handler, making everyone change their code
to use strerror_l (and get a locale_t to use it with) just to get back
the behavior they're used to seems like too much churn.

It would be nice if there was a way for strerror to detect that it
wasn't safe for it to call dcgettext or allocate memory.  In principle
we ought to be able to try-lock the "I might need to initialize the
global locale now" lock but, looking at the guts of dcgettext, there's
several different locks involved and it's not clear to me that we
could make this work without a major overhaul of libintl.

(Giant-hammer idea: have sigaction wrap all signal handlers with a
routine that sets a thread-local flag while calling the signal
handler.  siglongjmp and swapcontext would need to restore this flag.)

zw