Re: guard bug for strerror_r

[Rich Felker <dalias@aerifal.cx>]

On Fri, Feb 08, 2013 at 09:31:11PM +0100, Jens Gustedt wrote:
> And, also I think that even before the _r version would have been a
> good thing. I think the _r stands for reentrant, and for a function
> that you would typically like to use in error or signal handlers, this
> is a nice feature.

Yes, but unfortunately the _r's and use of the word "reentrant" in
issue 6 and earlier were all wrong; they used it to mean thread-safe,
not reentrant. None of the _r functions are required to be reentrant.
The term POSIX uses for reenatrant is "async-signal-safe", and
strerror_r is not async-signal-safe. This is not just a theoretical
limitation; in practice, most implementations probably fail to be
reentrant due to use of a mutex protecting access to the current
locale data.

If/when musl adds any locale state that would need synchronization, I
think our strerror should still be async-signal-safe, either using
musl's recursive mutex (which is also a reentrant mutex) or lock-free
atomic logic.

Rich