[Bug libstdc++/34733] numpunct::grouping() doesn't match libc value for Bulgarian (bg_BG) locale

["pcarlini at suse dot de" <gcc-bugzilla at gcc dot gnu dot org>]

------- Comment #10 from pcarlini at suse dot de  2008-01-11 10:18 -------
(In reply to comment #9)
> I don't agree that localeconv()->grouping is garbage just because thousands_sep
> is NUL. I'm not aware of anything in C or POSIX that says that.

We are working on this assumption. You agreed to it, at the beginning of this
thread. You agreed that, in C, a NUL as thousand separator in the localedata
means no grouping in C. The grouping must be not looked at, in that case (this
point is exactly what has been clarified to me, time ago, by glibc people) And
that makes perfect sense, because C strings cannot have a \0 in the middle. In
C, there is no meaningful way to group with \0.

 In the case of
> bg_BG, the grouping is clearly correct. What's questionable in this case is the
> value of thousands_sep. But that's probably just a bug in the Bulgarian locale
> definition.

That is another, glibc, issue, probably.

 Bugs aside, there may be a perfectly valid locale (a user-defined
> one) in which there is no thsousands_sep (i.e., it's NUL) but where grouping
> is non-empty. It's trivial to create one as an exercise. The C++ library
> numpunct should be able to represent such a locale without change.

Nobody disagrees with that! Maybe that was not clear in the previous messages.
Of course the user can do that, in C++, and the rationale is that basic_string
can have \0 in the middle. That seems obvious to me. No problem in v3, AFAIK,
but any issue here it's just a bug that will be fixed ASAP.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34733