In perl.git, the branch smoke-me/khw-locale has been created
<https://perl5.git.perl.org/perl.git/commitdiff/d64f54a1c92fef0460171062f675a408faec32ec?hp=0000000000000000000000000000000000000000>
at d64f54a1c92fef0460171062f675a408faec32ec (commit)
- Log -----------------------------------------------------------------
commit d64f54a1c92fef0460171062f675a408faec32ec
Author: Karl Williamson <k...@cpan.org>
Date: Mon Sep 11 18:57:54 2017 -0600
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.
-----------------------------------------------------------------------
--
Perl5 Master Repository
