From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5221 invoked by alias); 11 Jan 2008 10:19:13 -0000 Received: (qmail 5048 invoked by uid 48); 11 Jan 2008 10:18:30 -0000 Date: Fri, 11 Jan 2008 11:20:00 -0000 Message-ID: <20080111101830.5047.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug libstdc++/34733] numpunct::grouping() doesn't match libc value for Bulgarian (bg_BG) locale In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "pcarlini at suse dot de" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2008-01/txt/msg01019.txt.bz2 ------- 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