backport from blead: locale.c: Be sure to toggle into dot radix locale #22185
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This fixes GH Perl#21746 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 818cdb7 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.
|
@steve-m-hay has suggested a timing of just after 5.40 for a 5.38 maint to include this What other fixes need to go into this maintenance release? @leonerd @haarg @book, we need to get going on a maintenance release |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 818cdb7
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.