From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21842 invoked by alias); 14 Apr 2006 13:06:37 -0000 Received: (qmail 21834 invoked by uid 22791); 14 Apr 2006 13:06:37 -0000 X-Spam-Check-By: sourceware.org Received: from nile.gnat.com (HELO nile.gnat.com) (205.232.38.5) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 14 Apr 2006 13:06:35 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-nile.gnat.com (Postfix) with ESMTP id EAA5B48CC47; Fri, 14 Apr 2006 09:06:32 -0400 (EDT) Received: from nile.gnat.com ([127.0.0.1]) by localhost (nile.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 04794-01-5; Fri, 14 Apr 2006 09:06:32 -0400 (EDT) Received: from [127.0.0.1] (dhcp6.gnat.com [205.232.38.246]) by nile.gnat.com (Postfix) with ESMTP id BFFF348CBE0; Fri, 14 Apr 2006 09:06:32 -0400 (EDT) Message-ID: <443F9E59.7080704@adacore.com> Date: Fri, 14 Apr 2006 13:15:00 -0000 From: Robert Dewar User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Vladimir Prus CC: Eli Zaretskii , gdb@sources.redhat.com Subject: Re: printing wchar_t* References: <200604141246.58094.ghost@cs.msu.su> <200604141700.30020.ghost@cs.msu.su> In-Reply-To: <200604141700.30020.ghost@cs.msu.su> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-04/txt/msg00181.txt.bz2 Vladimir Prus wrote: > On Friday 14 April 2006 16:55, Eli Zaretskii wrote: >>> From: Vladimir Prus >>> Date: Fri, 14 Apr 2006 12:46:57 +0400 >>> Cc: gdb@sources.redhat.com >>> >>> No, I meant UTF-16 encoding (the one with surrogate pairs), and UTF-32 >>> encoding (which does exists, in the Unicode standard). >> What software uses that? > > I'd say, any software using std::wstring on Linux. > >> Anyway, UTF-16 is a variable-length encoding, so wchar_t is not it. > > Since C++ standard says nothing about encoding of wchar_t, specific > application can do anything it likes. In particular, I believe that on > Windows, wchar_t* is assumed to be in UTF-16 encoding. It only makes sense to talk about UTF-16 encoding in the context of wchar_t if wchar_t is 16-bits, otherwise, as noted above, UTF-32 is a variable length encoding, not suitable for wchar_t.