This cherry-pick from blead fixes GH #21746 and GH #22176
Perl keeps the LC_NUMERIC category in a locale where the radix character is a dot, regardless of what the user has requested. This is because much XS code has been written with the dot assumption. When the user's actual radix character is desired, the locale is briefly toggled to that one for the duration of the operation.
When the user changes the LC_NUMERIC locale, the new one is noted, but the attempted change is otherwise ignored unless its radix is a dot. The new one will be briefly toggled into when appropriate.
The blamed commit contains a logic error
commit 818cdb7aa9f85227c1c7313257c6204c872beb94
Author: Karl Williamson khw@cpan.org
AuthorDate: Sun Apr 11 05:57:07 2021 -0600
Commit: Karl Williamson khw@cpan.org
CommitDate: Thu Sep 1 09:02:04 2022 -0600
locale.c: Skip code if will be a no-op
It decided it was a no-op if the new locale that the user is changing to is the same as the previous locale. But it didn't consider that what actually happens is that the new locale does actually get changed, and this code is supposed to make sure that, before returning control to the user, that a dot radix locale is in effect.
If the new locale is a dot radix locale, then no harm is done by skipping the code, but otherwise things can go wrong.
I am chagrined that I made this logic error without noticing before it got pushed, and am surprised that it took this long for the error to surrface. There must be something else intervening to make this not a problem in most circumstances, but I haven't analyzed what it might be.
The details as to why it happened in this test case are pretty obscure. The locale in effect is looking for a comma radix, but what is being checked for is a Perl version number, like 5.0936. When converting that to a floating point number, the dot is not recognized, and only the initial '5' is found. The failing code in a module has different actions depending on the current perl version it is being called from, and the conditional got the answer wrong because 5 is less than 5.0936, whereas the actual version is above that. So it did the wrong thing and caused an error.
This cherry-pick from blead fixes GH #21746 and GH #22176
Perl keeps the LC_NUMERIC category in a locale where the radix character is a dot, regardless of what the user has requested. This is because much XS code has been written with the dot assumption. When the user's actual radix character is desired, the locale is briefly toggled to that one for the duration of the operation.
When the user changes the LC_NUMERIC locale, the new one is noted, but the attempted change is otherwise ignored unless its radix is a dot. The new one will be briefly toggled into when appropriate.
The blamed commit contains a logic error
commit 818cdb7aa9f85227c1c7313257c6204c872beb94 Author: Karl Williamson khw@cpan.org AuthorDate: Sun Apr 11 05:57:07 2021 -0600 Commit: Karl Williamson khw@cpan.org CommitDate: Thu Sep 1 09:02:04 2022 -0600
It decided it was a no-op if the new locale that the user is changing to is the same as the previous locale. But it didn't consider that what actually happens is that the new locale does actually get changed, and this code is supposed to make sure that, before returning control to the user, that a dot radix locale is in effect.
If the new locale is a dot radix locale, then no harm is done by skipping the code, but otherwise things can go wrong.
I am chagrined that I made this logic error without noticing before it got pushed, and am surprised that it took this long for the error to surrface. There must be something else intervening to make this not a problem in most circumstances, but I haven't analyzed what it might be.
The details as to why it happened in this test case are pretty obscure. The locale in effect is looking for a comma radix, but what is being checked for is a Perl version number, like 5.0936. When converting that to a floating point number, the dot is not recognized, and only the initial '5' is found. The failing code in a module has different actions depending on the current perl version it is being called from, and the conditional got the answer wrong because 5 is less than 5.0936, whereas the actual version is above that. So it did the wrong thing and caused an error.