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