icu::DateTimePatternGenerator::createInstance returns U_MISSING_RESOURCE_ERROR when default locale = ROOT and input locale is invalid
Description
Activity
Jeff Genovy April 25, 2019 at 5:51 PM
FWIW, I believe that ICU-20575 likely exacerbated this issue, by causing users with a “C.UTF-8” setting to inadvertently have a default locale of root.
Jeff Genovy April 25, 2019 at 6:18 AMEdited
So after doing some checking it seems that “C.UTF-8” no longer maps to “en_US_POSIX” as of ICU 64, yet “C” by itself does still map to “en_US_POSIX”. I filed a separate bug (ICU-20575) since it seems odd that it is no longer consistent.
Jeff Genovy April 24, 2019 at 10:49 PMEdited
Actually, I think the lack of mapping C → en_US_POSIX in ICU 64 might be due to this change: https://github.com/unicode-org/icu/pull/418
Jeff Genovy April 24, 2019 at 10:36 PM
FWIW, when testing on a Ubuntu system with ICU 64.1, when settingLANG=C.UTF-8
, the default locale reported by ICU was c
Ex:
$ LANG=C.UTF-8 icuinfo
...
<param name="locale.default">c</param>
<param name="locale.default.bcp47">und</param>
...
(Maybe the default locale setting only does Level 1 canonicalization? I think the C → en_US_POSIX is “Level 2” canonicalization?)
Steven R. Loomis April 24, 2019 at 10:30 PMEdited
@İsmail Dönmez C
should still have been automatically mapped to something else by the time it got to uloc_setDefault()
.
Reproduced the issue with ICU 63 and latest ICU codes.
int main(int argc, char **argv) { UErrorCode status = U_ZERO_ERROR; uloc_setDefault("root", &status); icu::DateTimePatternGenerator::createInstance("abc", status); // "abc" is a invalid local printf("Error:%s\n", u_errorName(status)); // Error:U_MISSING_RESOURCE_ERROR u_cleanup(); return 0; }
GoogleIssue:129070579