hamming_distance can hang or produce incorrect results #9349
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
facebook-github-bot
added
the
CLA Signed
|
This pull request was exported from Phabricator. Differential Revision: D55670296 |
✅ Deploy Preview for meta-velox canceled.
|
kevinwilfong
pushed a commit
to kevinwilfong/velox
that referenced
this pull request
Apr 3, 2024
…ator#9349) Summary: The call function for hamming_distance was written to iterate through two strings comparing UTF-8 characters. It uses utf8proc_codepoint to read those characters, it returns the character or the negative length of the invalid code point if it's invalid UTF-8. It then updates it's position in the string to either the number of bytes in the character, or the length of the invalid code point. The logic currently incorrectly treats ASCII 0 (the null character) as an invalid code point. Since the external library correctly treats it as a valid UTF-8 character it returns 0 for the character. The logic in hamming_distance treats 0 as the negative value of the length of the invalid code point, meaning it doesn't change it's position in the string. This means we return incorrect results if a null character appears in either string, as we incorrectly compute the length of the string with the null character. If both strings contain null characters, we end up in an infinite loop as neither string will make progress. Note that callAscii handles this correctly. Differential Revision: D55670296
kevinwilfong
force-pushed
the
export-D55670296
branch
from
03aa062
to
fdab0d6
Compare
|
This pull request was exported from Phabricator. Differential Revision: D55670296 |
|
CC: @wills-feng |
…ator#9349) Summary: The call function for hamming_distance was written to iterate through two strings comparing UTF-8 characters. It uses utf8proc_codepoint to read those characters, it returns the character or the negative length of the invalid code point if it's invalid UTF-8. It then updates it's position in the string to either the number of bytes in the character, or the length of the invalid code point. The logic currently incorrectly treats ASCII 0 (the null character) as an invalid code point. Since the external library correctly treats it as a valid UTF-8 character it returns 0 for the character. The logic in hamming_distance treats 0 as the negative value of the length of the invalid code point, meaning it doesn't change it's position in the string. This means we return incorrect results if a null character appears in either string, as we incorrectly compute the length of the string with the null character. If both strings contain null characters, we end up in an infinite loop as neither string will make progress. Note that callAscii handles this correctly. Reviewed By: kgpai Differential Revision: D55670296
kevinwilfong
force-pushed
the
export-D55670296
branch
from
fdab0d6
to
87bc046
Compare
|
This pull request was exported from Phabricator. Differential Revision: D55670296 |
mbasmanova
approved these changes
Apr 3, 2024
|
This pull request has been merged in bbbe224. |
|
Thanks for the fix. |
|
Conbench analyzed the 1 benchmark run on commit There were no benchmark performance regressions. 🎉 The full Conbench report has more details. |
Joe-Abraham
pushed a commit
to Joe-Abraham/velox
that referenced
this pull request
Apr 4, 2024
…ator#9349) Summary: Pull Request resolved: facebookincubator#9349 The call function for hamming_distance was written to iterate through two strings comparing UTF-8 characters. It uses utf8proc_codepoint to read those characters, it returns the character or the negative length of the invalid code point if it's invalid UTF-8. It then updates it's position in the string to either the number of bytes in the character, or the length of the invalid code point. The logic currently incorrectly treats ASCII 0 (the null character) as an invalid code point. Since the external library correctly treats it as a valid UTF-8 character it returns 0 for the character. The logic in hamming_distance treats 0 as the negative value of the length of the invalid code point, meaning it doesn't change it's position in the string. This means we return incorrect results if a null character appears in either string, as we incorrectly compute the length of the string with the null character. If both strings contain null characters, we end up in an infinite loop as neither string will make progress. Note that callAscii handles this correctly. Reviewed By: amitkdutta, kgpai Differential Revision: D55670296 fbshipit-source-id: 73d15b48b67f5342fe1c7904146c32dc5c34bd2e
Joe-Abraham
pushed a commit
to Joe-Abraham/velox
that referenced
this pull request
Jun 7, 2024
…ator#9349) Summary: Pull Request resolved: facebookincubator#9349 The call function for hamming_distance was written to iterate through two strings comparing UTF-8 characters. It uses utf8proc_codepoint to read those characters, it returns the character or the negative length of the invalid code point if it's invalid UTF-8. It then updates it's position in the string to either the number of bytes in the character, or the length of the invalid code point. The logic currently incorrectly treats ASCII 0 (the null character) as an invalid code point. Since the external library correctly treats it as a valid UTF-8 character it returns 0 for the character. The logic in hamming_distance treats 0 as the negative value of the length of the invalid code point, meaning it doesn't change it's position in the string. This means we return incorrect results if a null character appears in either string, as we incorrectly compute the length of the string with the null character. If both strings contain null characters, we end up in an infinite loop as neither string will make progress. Note that callAscii handles this correctly. Reviewed By: amitkdutta, kgpai Differential Revision: D55670296 fbshipit-source-id: 73d15b48b67f5342fe1c7904146c32dc5c34bd2e
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.
Summary:
The call function for hamming_distance was written to iterate through two strings comparing UTF-8 characters. It uses
utf8proc_codepoint to read those characters, it returns the character or the negative length of the invalid code point if it's
invalid UTF-8. It then updates it's position in the string to either the number of bytes in the character, or the length of the
invalid code point.
The logic currently incorrectly treats ASCII 0 (the null character) as an invalid code point. Since the external library correctly
treats it as a valid UTF-8 character it returns 0 for the character. The logic in hamming_distance treats 0 as the negative
value of the length of the invalid code point, meaning it doesn't change it's position in the string.
This means we return incorrect results if a null character appears in either string, as we incorrectly compute the length of the
string with the null character. If both strings contain null characters, we end up in an infinite loop as neither string will make
progress.
Note that callAscii handles this correctly.
Differential Revision: D55670296