Return more information from utf8_length_from_utf16_with_replacement#860
Merged
lemire merged 1 commit intosimdutf:devutf8lengthfrom Nov 21, 2025
Conversation
The next step after utf8_length_from_utf16_with_replacement is almost always going to be to allocate a UTF-8 buffer and then convert the string. Sadly, we have to insert a third pass, to_well_formed_utf16, which converts the unpaired surrogates. Since surrogates are relatively rare, and the _with_replacement functions have already scanned the input, we could skip the conversion if we were given this information along with the utf-8 length. In my measurements on Icelake this doesn't slow down utf8_length_from_utf16_with_replacement at all.
Member
|
I think that the only user is @anonrig, if so, I think we can allow a breaking change. |
Member
|
This PR is good and approved by @anonrig but I will merge it in a dev branch and do a bit of additional checks before our release. |
lemire
added a commit
that referenced
this pull request
Nov 22, 2025
* Return more information from utf8_length_from_utf16_with_replacement (#860) The next step after utf8_length_from_utf16_with_replacement is almost always going to be to allocate a UTF-8 buffer and then convert the string. Sadly, we have to insert a third pass, to_well_formed_utf16, which converts the unpaired surrogates. Since surrogates are relatively rare, and the _with_replacement functions have already scanned the input, we could skip the conversion if we were given this information along with the utf-8 length. In my measurements on Icelake this doesn't slow down utf8_length_from_utf16_with_replacement at all. * lint * better documentation. * version bump. * [no-ci] minor simplification * correct macro name. (!!!) * removing silly space --------- Co-authored-by: Erik Corry <[email protected]> Co-authored-by: Daniel Lemire <[email protected]>
1 task
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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.
The next step after utf8_length_from_utf16_with_replacement is almost always going to be to allocate a UTF-8 buffer and then convert the string. Sadly, we have to insert a third pass, to_well_formed_utf16, which converts the unpaired surrogates.
Since surrogates are relatively rare, and the _with_replacement functions have already scanned the input, we could skip the conversion if we were given this information along with the utf-8 length.
In my measurements on Icelake this doesn't slow down utf8_length_from_utf16_with_replacement at all.