------- Comment #3 from tsyvarev at ispras dot ru 2008-12-03 16:27 -------
Yes, I see, this is feature of glibc: for POSIX locale it defines
THOUSANDS_SEP, __MON_THOUSANDS_SEP and __MON_DECIMAL_POINT as "".
According to documentation for C-locale, this value means N/A (not assigned).
But this is seems not a bug - because in POSIX locale GROUPING is -1, grouping
is not applied to numbers, so THOUSANDS_SEP shouldn't be used. Also
__MON_THOUSANDS_SEP shouldn't be used (__MON_GROUPING is -1) and
__MON_DECIMAL_POINT (__MON_FRAC_DIGITS is -1).
C++ is dealing separately with "C" locale, so it may define some cases in its
own way. But it should do this in self-consitent manner - the standard stays,
that (from the description of name() method of locale, 22.1.1.3, p.5)
If *this has a name, then locale(name().c_str()) is equivalent to *this.
So, if for locale created via locale("C") numpunct<char>::thousands_sep()
returns ',' then
for every locale with name "C", even with only "LC_NUMERIC=C"
numpunct<char>::thousands_sep() should also return ',', not '\0'.
The same for moneypunct<char>::decimal_point() - because in locale("C") it
returns ".", it should return "." in any other locale with "LC_MONETARY=C".
moneypunct<char>::thousands_sep() return '\0' in locale("C") (intentionally or
unintentionally, i don't know), so in other locale with "LC_MONETARY=C" it can
return '\0', this isn't a bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38368
