Noticed as a test failure on glibc-2.31 system: FAIL: 22_locale/numpunct/members/char/3.cc execution test Test does """ // nl_NL chosen because it has no thousands separator (at this time). locale loc_it = locale(ISO_8859(15,nl_NL)); const numpunct<char>& nump_it = use_facet<numpunct<char> >(loc_it); string g = nump_it.grouping(); // Ensure that grouping is empty for locales with empty thousands separator. VERIFY( g == "" ); """ and expects "grouping 0;0". The failure started after glibc-2.30 update which changed nl_NL locale definition: -thousands_sep "" -grouping 0;0 +thousands_sep "." +grouping 3;3 https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=fefa21790b5081e5d04662a240e2efd18603ef86
Maybe pick another similar locale? Candidates are: glibc $ git grep '0;0' localedata/locales/ | cat localedata/locales/aa_DJ:grouping 0;0 localedata/locales/bs_BA:grouping 0;0 localedata/locales/el_CY:grouping 0;0 localedata/locales/el_GR:grouping 0;0 localedata/locales/eo:grouping 0;0 localedata/locales/es_CU:grouping 0;0 localedata/locales/gl_ES:grouping 0;0 localedata/locales/mg_MG:grouping 0;0 localedata/locales/pap_AW:grouping 0;0 localedata/locales/pap_CW:grouping 0;0 localedata/locales/pt_PT:grouping 0;0 localedata/locales/sl_SI:grouping 0;0 localedata/locales/sr_RS:grouping 0;0 localedata/locales/ti_ER:grouping 0;0 localedata/locales/wo_SN:grouping 0;0
We really need to create our own custom locales for testing, so that we don't depend on externally defined data that keep changing.
Good point. I tried pt_PT on FreeBSD to check if it's the same as in Linux and it's not: there grouping=3 is used. +1 for custom locale.