From mboxrd@z Thu Jan  1 00:00:00 1970
From: Anthony Liguori <anthony@codemonkey.ws>
Subject: Re: [Qemu-devel] KVM call minutes for Feb 15
Date: Thu, 17 Feb 2011 08:01:55 -0600
Message-ID: <4D5D2A53.30607@codemonkey.ws>
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> <AANLkTi=8zm4jcBM1sh16JQScOAOYhwcf0TkFp=tg_6bE@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Chris Wright <chrisw@redhat.com>, Avi Kivity <avi@redhat.com>,
	kvm@vger.kernel.org, qemu-devel@nongnu.org
To: Peter Maydell <peter.maydell@linaro.org>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mail-vx0-f174.google.com ([209.85.220.174]:40681 "EHLO
	mail-vx0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1750925Ab1BQOCV (ORCPT <rfc822;kvm@vger.kernel.org>);
	Thu, 17 Feb 2011 09:02:21 -0500
Received: by vxb37 with SMTP id 37so1099150vxb.19
        for <kvm@vger.kernel.org>; Thu, 17 Feb 2011 06:02:20 -0800 (PST)
In-Reply-To: <AANLkTi=8zm4jcBM1sh16JQScOAOYhwcf0TkFp=tg_6bE@mail.gmail.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

On 02/17/2011 07:59 AM, Peter Maydell wrote:
> On 17 February 2011 13:37, Anthony Liguori<anthony@codemonkey.ws>  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
>
>