This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug libstdc++/34733] numpunct::grouping() doesn't match libc value for Bulgarian (bg_BG) locale
- From: "pcarlini at suse dot de" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 11 Jan 2008 03:17:23 -0000
- Subject: [Bug libstdc++/34733] numpunct::grouping() doesn't match libc value for Bulgarian (bg_BG) locale
- References: <bug-34733-1186@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #6 from pcarlini at suse dot de 2008-01-11 03:17 -------
(In reply to comment #5)
> It's irrelevant to the implementation but it could be relevant to user-defined
> formatting (or parsing) code that bypasses num_put (or num_get) but uses
> numpunct to get the expected formats.
I'm not questioning that.
> IMO, the improvement in any Linux implementation (libstdc++ or stdcxx) lies in
> figuring out how to preserve the "\3\3" grouping and NUL thousands_sep for
> bg_BG (and expose each via numpunct::grouping() and numpunct::thousdands_sep())
> without causing num_put to insert NUL every three digits.
Frankly, I think it's impossible. Because the underlying glibc info says the
C++ library to not group. The locale does not group. In that case, I don't
think grouping() can be anything but the empty string. And I think 22.2.3.1.2/3
(and the rest of 22.2) almost enforces that explicitly. If you disagree with
that, I think we should file a DR.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34733