locale.c: strerror_l() not fool proof

Commit 7aaa36b196e5a478a3d1bd32506797db7cebf0b2 changed to use
strerror_l() if available on the platform.  But there is a potential bug
with this on threaded perls.  The code uses strerror_l() when it needs
the answer on a locale that isn't necessarily the current one.  But it
uses plain strerror() when the locale is known to be the current one.
Plain strerror() isn't necessarily thread-safe.  However, on systems
that have strerror_r(), reentr.h has caused our apparent call to plain
strerror() to instead call the thread-safe strerror_r() under the hood.
So there is no bug on unthreaded perls nor on ones that have
strerror_r().

This commit fixes the bug on threaded builds which have strerror_l() but
not strerror_r().  It does this by using strerror_l() for everything,
and constructing a locale object that is the current locale to use when
the locale doesn't need to be changed.  This is somewhat more work than
the alternative above does, so that one is used if available.

No changes are made to how it works on systems that don't have
strerror_l().

Some systems have deprecated strerror_r().  reentr.h does not use it on
such systems.  The reason for the deprecation, we would hope, may be
that the plain strerror() is implemented thread-safely.  We don't know
that, so we just assume that the plain version is thread-unsafe.

We do have tests that try to find races here, but they haven't shown
any.  It could be that systems that are advanced enough to have
strerror_l() also have strerror_r().

0 files changed, 0 insertions, 0 deletions