From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=60360 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pq4R5-0007HU-Tv for qemu-devel@nongnu.org; Thu, 17 Feb 2011 09:02:24 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pq4R3-0000l6-HQ for qemu-devel@nongnu.org; Thu, 17 Feb 2011 09:02:22 -0500 Received: from mail-vw0-f45.google.com ([209.85.212.45]:56211) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Pq4R3-0000ks-E2 for qemu-devel@nongnu.org; Thu, 17 Feb 2011 09:02:21 -0500 Received: by vws12 with SMTP id 12so1167414vws.4 for ; Thu, 17 Feb 2011 06:02:20 -0800 (PST) Message-ID: <4D5D2A53.30607@codemonkey.ws> Date: Thu, 17 Feb 2011 08:01:55 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] KVM call minutes for Feb 15 References: <20110215162629.GN21720@x200.localdomain> <4D5B0889.4030303@codemonkey.ws> <4D5BA5E9.90307@redhat.com> <4D5BD259.3080804@codemonkey.ws> <4D5CE9AB.2030503@redhat.com> <4D5D10C1.9010209@codemonkey.ws> <4D5D133F.4050801@redhat.com> <4D5D1E54.1070704@codemonkey.ws> <4D5D21C1.80009@redhat.com> <4D5D2496.8030900@codemonkey.ws> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Chris Wright , Avi Kivity , kvm@vger.kernel.org, qemu-devel@nongnu.org On 02/17/2011 07:59 AM, Peter Maydell wrote: > On 17 February 2011 13:37, Anthony Liguori wrote: > >> An application has to explicitly support an encoding. It is not >> transparent. UCS2/UTF-16 means that strings are not 'const char *'s but >> 'const wchar_t *' where typedef unsigned short wchar_t;. >> >> QEMU assumes, in lots of places that strings are single-byte NUL terminated. >> Basically, any use of snprintf, printf, strcpy, strlen, etc. pretty much >> tie you to ASCII/UTF-8. >> > Er, no, it limits you to those encodings where you can treat strings > as "bag of NUL-terminated bytes". Oddly enough just about all the > common legacy ones (iso-8859-*, iso-2022-jp, etc) fit in that category > because otherwise they'd break really badly. I wasn't even considering those because I think the entire world has moved to unicode/utf* Those functions limit you to UTF-8 which was my original point. Regards, Anthony Liguori > As it is, generally > things Just Work for programs which treat filenames as "an opaque > string". > > -- PMM > >