Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork33.3k
gh-60462: Fix locale.strxfrm() on Solaris#138242
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Uh oh!
There was an error while loading.Please reload this page.
Conversation
It should interpret the result of wcsxfrm() as a sequence of abstractintegers, not a sequence of Unicode code points or using other encodingscheme that does not preserve ordering.
ea8283a to60a5481Compare!buildbot Solaris |
bedevere-bot commentedAug 29, 2025
🤖 New build scheduled with the buildbot fleet by@serhiy-storchaka for commit60a5481 🤖 Results will be shown at: https://buildbot.python.org/all/#/grid?branch=refs%2Fpull%2F138242%2Fmerge The command will test the builders whose names match following regular expression: The builders matched are:
|
|
Thanks! I tested the patch on Solaris on both SPARC and Intel, and the tests are happy with it. That said, I am unsure whether it's correct to split the codes only when they are longer than 16 bits - couldn't that break the ordering? for example with values
-> comparing element by element, |
BTW, we are using similar patch on Solaris: |
Note |
Yes, it is surprisingly similar. You don't need to add 0x10000 if you split every character. My implementation needs this because it leaves 16-bit codes unchanged (this saves memory and time). More important, |
Oh, I completely overlooked that
That's true. I don't know if in can change order in our case, but it certainly shouldn't go through that |
Uh oh!
There was an error while loading.Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
LGTM
482fd0c intopython:mainUh oh!
There was an error while loading.Please reload this page.
Thanks@serhiy-storchaka for the PR 🌮🎉.. I'm working now to backport this PR to: 3.14. |
Thanks@serhiy-storchaka for the PR 🌮🎉.. I'm working now to backport this PR to: 3.13. |
It should interpret the result of wcsxfrm() as a sequence of abstractintegers, not a sequence of Unicode code points or using other encodingscheme that does not preserve ordering.(cherry picked from commit482fd0c)Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>
It should interpret the result of wcsxfrm() as a sequence of abstractintegers, not a sequence of Unicode code points or using other encodingscheme that does not preserve ordering.(cherry picked from commit482fd0c)Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>
GH-138448 is a backport of this pull request to the3.14 branch. |
GH-138449 is a backport of this pull request to the3.13 branch. |
It should interpret the result of wcsxfrm() as a sequence of abstractintegers, not a sequence of Unicode code points or using other encodingscheme that does not preserve ordering.(cherry picked from commit482fd0c)Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>
It should interpret the result of wcsxfrm() as a sequence of abstractintegers, not a sequence of Unicode code points or using other encodingscheme that does not preserve ordering.
It should interpret the result of wcsxfrm() as a sequence of abstractintegers, not a sequence of Unicode code points or using other encodingscheme that does not preserve ordering.(cherry picked from commit482fd0c)Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>
Uh oh!
There was an error while loading.Please reload this page.
It should interpret the result of wcsxfrm() as a sequence of abstract integers, not a sequence of Unicode code points or using other encoding scheme that does not preserve ordering.