icu::DateTimePatternGenerator::createInstance returns U_MISSING_RESOURCE_ERROR when default locale = ROOT and input locale is invalid

Description

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

Web links

Activity

Show:

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 AM
Edited

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 PM
Edited

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 PM
Edited

C should still have been automatically mapped to something else by the time it got to uloc_setDefault().

Fixed

Details

Assignee

Reporter

Components

Priority

Fix versions

Created April 12, 2019 at 5:52 PM
Updated May 22, 2019 at 5:53 PM
Resolved May 22, 2019 at 5:53 PM