From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28579 invoked by alias); 16 Jun 2004 14:18:04 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 28527 invoked by uid 48); 16 Jun 2004 14:18:03 -0000 Date: Wed, 16 Jun 2004 14:18:00 -0000 Message-ID: <20040616141803.28526.qmail@sourceware.org> From: "olau at hardworking dot dk" To: gcc-bugs@gcc.gnu.org In-Reply-To: <20040615164842.16006.olau@hardworking.dk> References: <20040615164842.16006.olau@hardworking.dk> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug libstdc++/16006] Conversions of numbers in fi_FI.UTF-8 produces incorrect UTF-8 X-Bugzilla-Reason: CC X-SW-Source: 2004-06/txt/msg01991.txt.bz2 List-Id: ------- Additional Comments From olau at hardworking dot dk 2004-06-16 14:17 ------- The %'d is to make it output the thousands separator. Look in the glibc manual: `'' Separate the digits into groups as specified by the locale specified for the `LC_NUMERIC' category; *note General Numeric::. This flag is a GNU extension. I'm not sure how you do it otherwise in C. But about the bug. You are wrong - the output is _not_ OK. It is not UTF-8. Run the program with .ISO-8859-1 instead of .UTF-8, and you get the non-breaking space in .ISO-8859-1. Then put that character through iconv from ISO-8859-1 to UTF-8 and you get _two_ characters, not one (in fact it could not possible be just one character when it's UTF-8). So glibc is right (produces correct UTF-8 non-breaking space) and libstdc++ is wrong (produces incorrect UTF-8 non-breaking space). The invalid UTF-8 from libstdc++ makes my GTK+ program die horrible. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16006