From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5469 invoked by alias); 16 Jun 2004 15:57:58 -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 5444 invoked by uid 48); 16 Jun 2004 15:57:57 -0000 Date: Wed, 16 Jun 2004 15:57:00 -0000 Message-ID: <20040616155757.5443.qmail@sourceware.org> From: "pcarlini at suse dot de" 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/msg02000.txt.bz2 List-Id: ------- Additional Comments From pcarlini at suse dot de 2004-06-16 15:57 ------- > This flag is a GNU extension. So, we are in the realm of -extensions-, not of Standard C. Ok, if you want to use that, but, beware, no consistency with the C++ Standard is guaranteed. > 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). In the ISO Standard the thousands separator is a -single- char_type of the -internal- encoding. Therefore, in general, in order to accomplish what you want, you have to use an internal encoding sufficiently wide (cout -> wcout) and also you have to call std::ios::sync_with_stdio(false) before any other I/O operation, otherwise no encoding to UTF-8 (from the internal representation) will take place (despite the imbue). Thanks, Paolo. -- What |Removed |Added ---------------------------------------------------------------------------- Status|WAITING |RESOLVED Resolution| |INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16006