[Perl/perl5] cb9df1: locale.c: Remove one use of nl_langinfo_l()

  Branch: refs/heads/blead
  Home:   https://github.com/Perl/perl5
  Commit: cb9df13091578d029ab318ba946310831d2e1912
      https://github.com/Perl/perl5/commit/cb9df13091578d029ab318ba946310831d2e1912
  Author: Karl Williamson <khw@cpan.org>
  Date:   2023-03-13 (Mon, 13 Mar 2023)

  Changed paths:
    M locale.c
    M perl.h

  Log Message:
  -----------
  locale.c: Remove one use of nl_langinfo_l()

The limited POSIX guarantees of thread safety for nl_langinfo_l() aren't
enough for our uses, and I was naive to think that a simple Configure probe
could rule out all possible thread-safety issues that might exist in a
libc call.  I don't remember what the platforms were that falsely tested
ok for the probe, but if it were necessary to find out, revert this
patch, and start a smoke-me test.

What that Configure probe did was find one particular point of
non-safety.  And it turns out various platforms pass that, but don't
have a thread-safe nl_langinfo_l() generally.

There are two calls to nl_langinfo_l() in the code.  This commit removes
one, where the major advantage of using nl_langinfo_l() over plain
nl_langinfo() was efficiency.  There still had to be an alternate
implementation available that used plain nl_langinfo().  Since we can't
guarantee that the _l implementation doesn't have bugs, simply remove
it, and the existing alternative gets automatically used.

The remaining use of nl_langinfo_l() is only when using glibc, and is
disabled by default, requiring an explicit Configure parameter to
enable.  I have never seen a case where the glibc implementation failed
to be thread-safe.  This use may be enabled by default at some point,
but not until early in a development cycle.

• [Perl/perl5] cb9df1: locale.c: Remove one use of nl_langinfo_l() by Karl Williamson via perl5-changes