Branch: refs/heads/smoke-me/khw-20085
Home: https://github.com/Perl/perl5
Commit: e2660cb43220f44b1e41c31919b33459cedc8370
https://github.com/Perl/perl5/commit/e2660cb43220f44b1e41c31919b33459cedc8370
Author: Karl Williamson <[email protected]>
Date: 2022-08-14 (Sun, 14 Aug 2022)
Changed paths:
M locale.c
Log Message:
-----------
locale.c: Clarify comment
Commit: 6c9b0cc49a0bd8d5a468dfc33853230d3cce070f
https://github.com/Perl/perl5/commit/6c9b0cc49a0bd8d5a468dfc33853230d3cce070f
Author: Karl Williamson <[email protected]>
Date: 2022-08-14 (Sun, 14 Aug 2022)
Changed paths:
M locale.c
Log Message:
-----------
locale.c: Remove redundant loop iteration
This loop recalculates LC_ALL on the final non-LC_ALL iteration, and
then it did an extra iteration, just to recalculate LC_ALL. This is
unnecessary and could cause memory leaks.
Commit: 9e56febb1279a8d27f3565252cfbc2460b2daaa6
https://github.com/Perl/perl5/commit/9e56febb1279a8d27f3565252cfbc2460b2daaa6
Author: Karl Williamson <[email protected]>
Date: 2022-08-14 (Sun, 14 Aug 2022)
Changed paths:
M embed.fnc
M locale.c
M proto.h
Log Message:
-----------
locale.c: Imnprove LC_ALL recalculation determination
As explained in the comments, on systems that lack the ability to query
what the current locale is, we have to keep track of it ourselves. Each
time a single category changes, LC_ALL which is the sum of all
catgegories, also changes, and there is a non-trivial amount of work in
calculating the new value. In a tight loop that sets all category
components, all that work except the final iteration would be thrown
away. I came up with a kludgy method to signal that the work would be
thrown away, so skip it.
Years later, I see a cleaner way to accomplish the same thing, by using
a macro to hide the calculation details, and then using that macro in
the few necessary places.
Commit: 423f0592a430809e74b5144a8b8daa8602461fa4
https://github.com/Perl/perl5/commit/423f0592a430809e74b5144a8b8daa8602461fa4
Author: Karl Williamson <[email protected]>
Date: 2022-08-14 (Sun, 14 Aug 2022)
Changed paths:
M locale.c
M t/run/locale.t
Log Message:
-----------
locale.c: Make sure LC_ALL gets changed when necessary
This fixes #20085.
POSIX failed to define a way to find out what the current locale is,
in the new API for thread-safe locales, introduced in the 2008 version
of the standard. (That has finally been changed in the 2017 version,
but I am unaware of any accessible boxes implementing it.)
Darwin added their own extension to accomplish this, and Windows instead
used an extension to the old API to accomplish thread-safety. And glibc
has their own, hidden extension, which it's possible to Configure Perl
to use, but, since, it's not documented, it is not enabled by default.
Perl maps the old API to the new one when compiled for threads, and
where thread-safety is available. On Configurations where there isn't
the ability to query the current locale, it itself keeps a record of
that information, maintained from start-up of the process.
The commit blamed in the ticket changed things so that when calling the
function that changes a category's locale, if the value to change to is
the same as it already was, it is a no-op.
But LC_ALL is the sum of all the other locale categories. If any one of
them changes, LC_ALL must be updated. There are occasions where all
categories are updated in a tight loop, and, to save unnecessary work,
only the final iteration updates LC_ALL (as each iteration would throw
away the results of the previous iteration).
The blamed commit inadvertently caused the code to skip updating LC_ALL
when the final iteration wouldn't result in a change in the locale of
its category, whereas LC_ALL should have been updated on that iteration
if any previous iteration affected a change.
This new commit causes LC_ALL to always be updated on the final
iteration, regardless of what happened in the previous ones. To only
update it when absolutely necessary, we would have to have an extra
internal state indicating that we are in a loop and whether changes have
occurred while in that loop. That's certainly feasible, I don't think
the extra complexity is worth it.
Compare: https://github.com/Perl/perl5/compare/e2660cb43220%5E...423f0592a430
