ICU-21449 Infinite loop can occur with locale IDs that contain RES_PATH_SEPARATOR #1549
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
daniel-ju
approved these changes
Jan 28, 2021
jefgen
added a commit
to microsoft/icu
that referenced
this pull request
Jan 29, 2021
…ontain RES_PATH_SEPARATOR Upstream ticket: https://unicode-org.atlassian.net/browse/ICU-21449 Upstream PR: unicode-org/icu#1549
5 tasks
jefgen
added a commit
to microsoft/icu
that referenced
this pull request
Feb 1, 2021
…ontain RES_PATH_SEPARATOR (#66) This change cherry-picks the upstream fix for the issue of an infinite loop when calling various APIs with locale IDs that contain `RES_PATH_SEPARATOR`. Upstream ticket: https://unicode-org.atlassian.net/browse/ICU-21449 Upstream PR: unicode-org/icu#1549 Detailed Description (from the upstream PR): When calling APIs like `uloc_getDisplayLanguage`, if the input locale ID has `/` (the `RES_PATH_SEPARATOR` value) then the resource look-up code ends up in an infinite loop. For example, the following code will never return: ```c++ UErrorCode status = U_ZERO_ERROR; const char* localeNameTemp = "/"; // RES_PATH_SEPARATOR uloc_getDisplayLanguage(localeNameTemp, localeNameTemp, NULL, 0, &status); ``` The `do {...} while` loop in `ures_getByKeyWithFallback` calls `res_findResource`, but it never checks to see if the returned resource is `RES_BOGUS`, meaning that for some paths it will never terminate. (Thanks to am11 for doing the initial investigation into this issue.) This PR also includes a test case for the issue. Note that there is nothing really "tested" by the test case, as the test is to simply ensure that calling the API doesn't cause a hang due to the infinite loop.
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.
When calling APIs like
uloc_getDisplayLanguage, if the input locale ID has/(theRES_PATH_SEPARATORvalue) then the resource look-up code ends up in an infinite loop.For example, the following code will never return:
The
do {...} whileloop inures_getByKeyWithFallbackcallsres_findResource, but it never checks to see if the returned resource isRES_BOGUS, meaning that for some paths it will never terminate. (Thanks to am11 for doing the initial investigation into this issue.)This PR also includes a test case for the issue. Note that there is nothing really "tested" by the test case, as the test is to simply ensure that calling the API doesn't cause a hang due to the infinite loop.
Checklist