From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([209.51.188.92]:42080) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hGK0j-0007AV-QM for qemu-devel@nongnu.org; Tue, 16 Apr 2019 05:04:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hGK0h-0008HI-Se for qemu-devel@nongnu.org; Tue, 16 Apr 2019 05:04:13 -0400 Received: from mx1.redhat.com ([209.132.183.28]:45532) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hGK0f-0008Fb-NX for qemu-devel@nongnu.org; Tue, 16 Apr 2019 05:04:11 -0400 Date: Tue, 16 Apr 2019 10:03:58 +0100 From: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= Message-ID: <20190416090358.GF31311@redhat.com> Reply-To: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= References: <20190415141547.15444-1-berrange@redhat.com> <87a7gq75l6.fsf@dusky.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <87a7gq75l6.fsf@dusky.pond.sub.org> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v2] vl: set LC_CTYPE early in main() for all code List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: qemu-devel@nongnu.org, Bandan Das , Gerd Hoffmann , Paolo Bonzini , Samuel Thibault On Tue, Apr 16, 2019 at 09:49:09AM +0200, Markus Armbruster wrote: > Daniel P. Berrang=C3=A9 writes: >=20 > > Localization is not a feature whose impact is limited to the UI > > frontends. Other parts of QEMU rely in localization. >=20 > Typically by accident :) >=20 > > In particular th= e > > USB MTP driver needs to be able to convert filenames from the locale > > specified character set into UTF-16 / UCS-2 encoded wide characters. >=20 > Oookay. I guess that makes some sense. >=20 > > setlocale() is only set from two of the UI frontends though, and wors= e, > > there is inconsistent behaviour with GTK setting LC_CTYPE to C.UTF-8, > > while ncurses honours whatever is set in the user's environment. > > > > This causes the USP MTP driver to behave differently depending on whi= ch > > UI frontend is activated. > > > > Furthermore, the curses settings are dangerous because LC_CTYPE will = affect > > the is{upper,lower,alnum} functions which much QEMU code assumes to h= ave > > C locale sorting behaviour. This also breaks QMP if the env requests = a > > non-UTF-8 locale, since QMP is defined to use UTF-8 encoding for JSON= . >=20 > Can you elaborate on how QMP breaks with a non-UTF-8 locale? Ah, you d= o > in the comment you add to vl.c. >=20 > > This problematic curses code was introduced in: > > > > commit 2f8b7cd587558944532f587abb5203ce54badba9 > > Author: Samuel Thibault > > Date: Mon Mar 11 14:51:27 2019 +0100 > > > > curses: add option to specify VGA font encoding > > > > This patch moves the GTK frontend setlocale() handling into the main(= ) > > method. This ensures QMP and other QEMU code has a predictable C.UTF-= 8. > > > > Eventually QEMU should set LC_ALL, honouring the full user environmen= t, > > but this needs various cleanups in QEMU code first. >=20 > Eventually, we'll all be dead. >=20 > > Hardcoding LC_CTY= PE > > to C.UTF-8 is a partial regression vs the above curses commit, since = it > > will break the curses wide character handling for non-UTF-8 locales b= ut > > this is unavoidable until QEMU is cleaned up to cope with non-UTF-8 > > locales fully. > > > > Setting of LC_MESSAGES is left in the GTK code since only the GTK > > frontend is using translation of strings. This lets us avoid the > > platform portability problem where LC_MESSAGES is not provided by > > locale.h on MinGW. GTK pulls it in indirectly from libintl.h via > > gi18n.h header, but we don't want to pull that into the global > > QEMU namespace. > > > > Signed-off-by: Daniel P. Berrang=C3=A9 > > --- > > > > Changed in v2: > > > > - Leave LC_MESSAGES setting in gtk code to avoid platform > > portability problems. > > > > ui/curses.c | 2 -- > > ui/gtk.c | 32 +++++++++++--------------------- > > vl.c | 40 ++++++++++++++++++++++++++++++++++++++++ > > 3 files changed, 51 insertions(+), 23 deletions(-) > > > > diff --git a/ui/curses.c b/ui/curses.c > > index cc6d6da684..403cd57913 100644 > > --- a/ui/curses.c > > +++ b/ui/curses.c > > @@ -27,7 +27,6 @@ > > #include > > #include > > #endif > > -#include > > #include > > #include > > #include > > @@ -716,7 +715,6 @@ static void curses_display_init(DisplayState *ds,= DisplayOptions *opts) > > } > > #endif > > =20 > > - setlocale(LC_CTYPE, ""); > > if (opts->u.curses.charset) { > > font_charset =3D opts->u.curses.charset; > > } > > diff --git a/ui/gtk.c b/ui/gtk.c > > index e96e15435a..e6a41c79ab 100644 > > --- a/ui/gtk.c > > +++ b/ui/gtk.c > > @@ -2208,12 +2208,12 @@ static void gtk_display_init(DisplayState *ds= , DisplayOptions *opts) > > =20 > > s->free_scale =3D FALSE; > > =20 > > - /* Mostly LC_MESSAGES only. See early_gtk_display_init() for det= ails. For > > - * LC_CTYPE, we need to make sure that non-ASCII characters are = considered > > - * printable, but without changing any of the character classes = to make > > - * sure that we don't accidentally break implicit assumptions. = */ > > + /* > > + * See comment in main() for why it has only setup LC_CTYPE, > > + * as opposed to LC_ALL. Given that we need to enable > > + * LC_MESSAGES too for menu translations. > > + */ > > setlocale(LC_MESSAGES, ""); > > - setlocale(LC_CTYPE, "C.UTF-8"); > > bindtextdomain("qemu", CONFIG_QEMU_LOCALEDIR); > > textdomain("qemu"); > > =20 > > @@ -2262,22 +2262,12 @@ static void gtk_display_init(DisplayState *ds= , DisplayOptions *opts) > > =20 > > static void early_gtk_display_init(DisplayOptions *opts) > > { > > - /* The QEMU code relies on the assumption that it's always run i= n > > - * the C locale. Therefore it is not prepared to deal with > > - * operations that produce different results depending on the > > - * locale, such as printf's formatting of decimal numbers, and > > - * possibly others. > > - * > > - * Since GTK+ calls setlocale() by default -importing the locale > > - * settings from the environment- we must prevent it from doing = so > > - * using gtk_disable_setlocale(). > > - * > > - * QEMU's GTK+ UI, however, _does_ have translations for some of > > - * the menu items. As a trade-off between a functionally correct > > - * QEMU and a fully internationalized UI we support importing > > - * LC_MESSAGES from the environment (see the setlocale() call > > - * earlier in this file). This allows us to display translated > > - * messages leaving everything else untouched. > > + /* > > + * GTK calls setlocale() by default, importing the locale > > + * settings from the environment. QEMU's main() method will > > + * have set LC_MESSAGES and LC_CTYPE to allow GTK to display > > + * translated messages, including use of wide characters. We > > + * must not allow GTK to change other aspects of the locale. > > */ > > gtk_disable_setlocale(); > > gtkinit =3D gtk_init_check(NULL, NULL); > > diff --git a/vl.c b/vl.c > > index c696ad2a13..87a55cddb3 100644 > > --- a/vl.c > > +++ b/vl.c > > @@ -49,6 +49,7 @@ int main(int argc, char **argv) > > #define main qemu_main > > #endif /* CONFIG_COCOA */ > > =20 > > +#include > > =20 > > #include "qemu/error-report.h" > > #include "qemu/sockets.h" > > @@ -3022,6 +3023,45 @@ int main(int argc, char **argv, char **envp) > > char *dir, **dirs; > > BlockdevOptionsQueue bdo_queue =3D QSIMPLEQ_HEAD_INITIALIZER(bdo= _queue); > > =20 > > + /* > > + * Ideally we would set LC_ALL, but QEMU currently isn't able to= cope > > + * with arbitrary localization settings. In particular there are= two > > + * known problems > > + * > > + * - The QMP monitor needs to use the C locale rules for numer= ic > > + * formatting. This would need a double/int -> string format= ter > > + * that is locale independant. >=20 > Aha. >=20 > Reminds me of the story of a FORTRAN compiler that rejected only > far-away customers' programs... >=20 > > + * > > + * - The QMP monitor needs to encode all data as UTF-8. This n= eeds > > + * to be updated to use iconv(3) to explicitly convert the c= urrent > > + * locale's charset into utf-8 >=20 > Really? What locale-dependent text gets sent to QMP? The main thing I can see would be filenames. Though having said it is UTF-8 on looking more closely I think QEMU is probably 8-bit clean in its handling, so will just be blindly passing whatever filename string it get from libvirt straight on to the kernel with no interpretation. Libvirt has enabled UTF-8 validation in its JSON library when encoding data it sends to QEMU, so any data libvirt is sending will be a valid UTF-8 byte sequence at least. Libvirt doesn't axctually do any charset conversion though, so if libvirt runs in a non-UTF8 locale it will likely trip over this UTF-8 validation. >=20 > > + * > > + * - Lots of codes uses is{upper,lower,alnum,...} functions, e= xpecting > > + * C locale sorting behaviour. Most QEMU usage should likely= be > > + * changed to g_ascii_is{upper,lower,alnum...} to match code > > + * assumptions, without being broken by locale settnigs. > > + * > > + * We do still have two requirements > > + * > > + * - Ability to correct display translated text according to t= he > > + * user's locale > > + * > > + * - Ability to handle multibyte characters, ideally according= to > > + * user's locale specified character set. This affects abili= ty > > + * of usb-mtp to correctly convert filenames to UCS16 and cu= rses > > + * & GTK frontends wide character display. > > + * > > + * The second requirement would need LC_CTYPE to be honoured, bu= t > > + * this conflicts with the 2nd & 3rd problems listed earlier. Fo= r > > + * now we make a tradeoff, trying to set an explicit UTF-8 local= ee > > + * > > + * Note we can't set LC_MESSAGES here, since mingw doesn't defin= e > > + * this constant in locale.h Fortunately we only need it for the > > + * GTK frontend and that uses gi18n.h which pulls in a definitio= n > > + * of LC_MESSAGES. > > + */ > > + setlocale(LC_CTYPE, "C.UTF-8"); > > + > > module_call_init(MODULE_INIT_TRACE); > > =20 > > qemu_init_cpu_list(); >=20 > We should've stayed out of the GUI business. This isn't only a GUI problem as above, it affects USB MTP. Regards, Daniel --=20 |: https://berrange.com -o- https://www.flickr.com/photos/dberran= ge :| |: https://libvirt.org -o- https://fstop138.berrange.c= om :| |: https://entangle-photo.org -o- https://www.instagram.com/dberran= ge :| From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.3 required=3.0 tests=FROM_EXCESS_BASE64, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_PASS,URIBL_BLOCKED,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E4D7AC10F14 for ; Tue, 16 Apr 2019 09:05:19 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id A234E20645 for ; Tue, 16 Apr 2019 09:05:19 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A234E20645 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([127.0.0.1]:33422 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hGK1n-0007gb-04 for qemu-devel@archiver.kernel.org; Tue, 16 Apr 2019 05:05:19 -0400 Received: from eggs.gnu.org ([209.51.188.92]:42080) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hGK0j-0007AV-QM for qemu-devel@nongnu.org; Tue, 16 Apr 2019 05:04:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hGK0h-0008HI-Se for qemu-devel@nongnu.org; Tue, 16 Apr 2019 05:04:13 -0400 Received: from mx1.redhat.com ([209.132.183.28]:45532) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hGK0f-0008Fb-NX for qemu-devel@nongnu.org; Tue, 16 Apr 2019 05:04:11 -0400 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 2D72187632; Tue, 16 Apr 2019 09:04:08 +0000 (UTC) Received: from redhat.com (ovpn-112-50.ams2.redhat.com [10.36.112.50]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 574245C220; Tue, 16 Apr 2019 09:04:01 +0000 (UTC) Date: Tue, 16 Apr 2019 10:03:58 +0100 From: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= To: Markus Armbruster Message-ID: <20190416090358.GF31311@redhat.com> References: <20190415141547.15444-1-berrange@redhat.com> <87a7gq75l6.fsf@dusky.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline In-Reply-To: <87a7gq75l6.fsf@dusky.pond.sub.org> User-Agent: Mutt/1.11.3 (2019-02-01) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Tue, 16 Apr 2019 09:04:08 +0000 (UTC) Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.132.183.28 Subject: Re: [Qemu-devel] [PATCH v2] vl: set LC_CTYPE early in main() for all code X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= Cc: Paolo Bonzini , Bandan Das , qemu-devel@nongnu.org, Samuel Thibault , Gerd Hoffmann Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" Message-ID: <20190416090358.ras3NWsCQOIz4GNOvlOD97aei1DDYE73soRvlsYNCb4@z> On Tue, Apr 16, 2019 at 09:49:09AM +0200, Markus Armbruster wrote: > Daniel P. Berrang=C3=A9 writes: >=20 > > Localization is not a feature whose impact is limited to the UI > > frontends. Other parts of QEMU rely in localization. >=20 > Typically by accident :) >=20 > > In particular th= e > > USB MTP driver needs to be able to convert filenames from the locale > > specified character set into UTF-16 / UCS-2 encoded wide characters. >=20 > Oookay. I guess that makes some sense. >=20 > > setlocale() is only set from two of the UI frontends though, and wors= e, > > there is inconsistent behaviour with GTK setting LC_CTYPE to C.UTF-8, > > while ncurses honours whatever is set in the user's environment. > > > > This causes the USP MTP driver to behave differently depending on whi= ch > > UI frontend is activated. > > > > Furthermore, the curses settings are dangerous because LC_CTYPE will = affect > > the is{upper,lower,alnum} functions which much QEMU code assumes to h= ave > > C locale sorting behaviour. This also breaks QMP if the env requests = a > > non-UTF-8 locale, since QMP is defined to use UTF-8 encoding for JSON= . >=20 > Can you elaborate on how QMP breaks with a non-UTF-8 locale? Ah, you d= o > in the comment you add to vl.c. >=20 > > This problematic curses code was introduced in: > > > > commit 2f8b7cd587558944532f587abb5203ce54badba9 > > Author: Samuel Thibault > > Date: Mon Mar 11 14:51:27 2019 +0100 > > > > curses: add option to specify VGA font encoding > > > > This patch moves the GTK frontend setlocale() handling into the main(= ) > > method. This ensures QMP and other QEMU code has a predictable C.UTF-= 8. > > > > Eventually QEMU should set LC_ALL, honouring the full user environmen= t, > > but this needs various cleanups in QEMU code first. >=20 > Eventually, we'll all be dead. >=20 > > Hardcoding LC_CTY= PE > > to C.UTF-8 is a partial regression vs the above curses commit, since = it > > will break the curses wide character handling for non-UTF-8 locales b= ut > > this is unavoidable until QEMU is cleaned up to cope with non-UTF-8 > > locales fully. > > > > Setting of LC_MESSAGES is left in the GTK code since only the GTK > > frontend is using translation of strings. This lets us avoid the > > platform portability problem where LC_MESSAGES is not provided by > > locale.h on MinGW. GTK pulls it in indirectly from libintl.h via > > gi18n.h header, but we don't want to pull that into the global > > QEMU namespace. > > > > Signed-off-by: Daniel P. Berrang=C3=A9 > > --- > > > > Changed in v2: > > > > - Leave LC_MESSAGES setting in gtk code to avoid platform > > portability problems. > > > > ui/curses.c | 2 -- > > ui/gtk.c | 32 +++++++++++--------------------- > > vl.c | 40 ++++++++++++++++++++++++++++++++++++++++ > > 3 files changed, 51 insertions(+), 23 deletions(-) > > > > diff --git a/ui/curses.c b/ui/curses.c > > index cc6d6da684..403cd57913 100644 > > --- a/ui/curses.c > > +++ b/ui/curses.c > > @@ -27,7 +27,6 @@ > > #include > > #include > > #endif > > -#include > > #include > > #include > > #include > > @@ -716,7 +715,6 @@ static void curses_display_init(DisplayState *ds,= DisplayOptions *opts) > > } > > #endif > > =20 > > - setlocale(LC_CTYPE, ""); > > if (opts->u.curses.charset) { > > font_charset =3D opts->u.curses.charset; > > } > > diff --git a/ui/gtk.c b/ui/gtk.c > > index e96e15435a..e6a41c79ab 100644 > > --- a/ui/gtk.c > > +++ b/ui/gtk.c > > @@ -2208,12 +2208,12 @@ static void gtk_display_init(DisplayState *ds= , DisplayOptions *opts) > > =20 > > s->free_scale =3D FALSE; > > =20 > > - /* Mostly LC_MESSAGES only. See early_gtk_display_init() for det= ails. For > > - * LC_CTYPE, we need to make sure that non-ASCII characters are = considered > > - * printable, but without changing any of the character classes = to make > > - * sure that we don't accidentally break implicit assumptions. = */ > > + /* > > + * See comment in main() for why it has only setup LC_CTYPE, > > + * as opposed to LC_ALL. Given that we need to enable > > + * LC_MESSAGES too for menu translations. > > + */ > > setlocale(LC_MESSAGES, ""); > > - setlocale(LC_CTYPE, "C.UTF-8"); > > bindtextdomain("qemu", CONFIG_QEMU_LOCALEDIR); > > textdomain("qemu"); > > =20 > > @@ -2262,22 +2262,12 @@ static void gtk_display_init(DisplayState *ds= , DisplayOptions *opts) > > =20 > > static void early_gtk_display_init(DisplayOptions *opts) > > { > > - /* The QEMU code relies on the assumption that it's always run i= n > > - * the C locale. Therefore it is not prepared to deal with > > - * operations that produce different results depending on the > > - * locale, such as printf's formatting of decimal numbers, and > > - * possibly others. > > - * > > - * Since GTK+ calls setlocale() by default -importing the locale > > - * settings from the environment- we must prevent it from doing = so > > - * using gtk_disable_setlocale(). > > - * > > - * QEMU's GTK+ UI, however, _does_ have translations for some of > > - * the menu items. As a trade-off between a functionally correct > > - * QEMU and a fully internationalized UI we support importing > > - * LC_MESSAGES from the environment (see the setlocale() call > > - * earlier in this file). This allows us to display translated > > - * messages leaving everything else untouched. > > + /* > > + * GTK calls setlocale() by default, importing the locale > > + * settings from the environment. QEMU's main() method will > > + * have set LC_MESSAGES and LC_CTYPE to allow GTK to display > > + * translated messages, including use of wide characters. We > > + * must not allow GTK to change other aspects of the locale. > > */ > > gtk_disable_setlocale(); > > gtkinit =3D gtk_init_check(NULL, NULL); > > diff --git a/vl.c b/vl.c > > index c696ad2a13..87a55cddb3 100644 > > --- a/vl.c > > +++ b/vl.c > > @@ -49,6 +49,7 @@ int main(int argc, char **argv) > > #define main qemu_main > > #endif /* CONFIG_COCOA */ > > =20 > > +#include > > =20 > > #include "qemu/error-report.h" > > #include "qemu/sockets.h" > > @@ -3022,6 +3023,45 @@ int main(int argc, char **argv, char **envp) > > char *dir, **dirs; > > BlockdevOptionsQueue bdo_queue =3D QSIMPLEQ_HEAD_INITIALIZER(bdo= _queue); > > =20 > > + /* > > + * Ideally we would set LC_ALL, but QEMU currently isn't able to= cope > > + * with arbitrary localization settings. In particular there are= two > > + * known problems > > + * > > + * - The QMP monitor needs to use the C locale rules for numer= ic > > + * formatting. This would need a double/int -> string format= ter > > + * that is locale independant. >=20 > Aha. >=20 > Reminds me of the story of a FORTRAN compiler that rejected only > far-away customers' programs... >=20 > > + * > > + * - The QMP monitor needs to encode all data as UTF-8. This n= eeds > > + * to be updated to use iconv(3) to explicitly convert the c= urrent > > + * locale's charset into utf-8 >=20 > Really? What locale-dependent text gets sent to QMP? The main thing I can see would be filenames. Though having said it is UTF-8 on looking more closely I think QEMU is probably 8-bit clean in its handling, so will just be blindly passing whatever filename string it get from libvirt straight on to the kernel with no interpretation. Libvirt has enabled UTF-8 validation in its JSON library when encoding data it sends to QEMU, so any data libvirt is sending will be a valid UTF-8 byte sequence at least. Libvirt doesn't axctually do any charset conversion though, so if libvirt runs in a non-UTF8 locale it will likely trip over this UTF-8 validation. >=20 > > + * > > + * - Lots of codes uses is{upper,lower,alnum,...} functions, e= xpecting > > + * C locale sorting behaviour. Most QEMU usage should likely= be > > + * changed to g_ascii_is{upper,lower,alnum...} to match code > > + * assumptions, without being broken by locale settnigs. > > + * > > + * We do still have two requirements > > + * > > + * - Ability to correct display translated text according to t= he > > + * user's locale > > + * > > + * - Ability to handle multibyte characters, ideally according= to > > + * user's locale specified character set. This affects abili= ty > > + * of usb-mtp to correctly convert filenames to UCS16 and cu= rses > > + * & GTK frontends wide character display. > > + * > > + * The second requirement would need LC_CTYPE to be honoured, bu= t > > + * this conflicts with the 2nd & 3rd problems listed earlier. Fo= r > > + * now we make a tradeoff, trying to set an explicit UTF-8 local= ee > > + * > > + * Note we can't set LC_MESSAGES here, since mingw doesn't defin= e > > + * this constant in locale.h Fortunately we only need it for the > > + * GTK frontend and that uses gi18n.h which pulls in a definitio= n > > + * of LC_MESSAGES. > > + */ > > + setlocale(LC_CTYPE, "C.UTF-8"); > > + > > module_call_init(MODULE_INIT_TRACE); > > =20 > > qemu_init_cpu_list(); >=20 > We should've stayed out of the GUI business. This isn't only a GUI problem as above, it affects USB MTP. Regards, Daniel --=20 |: https://berrange.com -o- https://www.flickr.com/photos/dberran= ge :| |: https://libvirt.org -o- https://fstop138.berrange.c= om :| |: https://entangle-photo.org -o- https://www.instagram.com/dberran= ge :|