[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lmi] UTF-16 output from automated GUI test?
From: |
Greg Chicares |
Subject: |
Re: [lmi] UTF-16 output from automated GUI test? |
Date: |
Thu, 20 Oct 2016 01:14:29 +0000 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.3.0 |
On 2016-10-19 23:24, Vadim Zeitlin wrote:
> On Wed, 19 Oct 2016 22:29:48 +0000 Greg Chicares <address@hidden> wrote:
>
> GC> To reproduce:
> GC> cd /opt/lmi/bin
> GC> ./wx_test.exe --ash_nazg --data_path=/opt/lmi/data >eraseme 2>&1
> GC> od -t a eraseme |head
> ...
> GC> I was expecting "NOTE:" instead of "address@hidden@address@hidden@:^@".
>
> Interesting, I don't see this under MSW 7 here. Do you run this inside the
> native command line prompt window or in a Cygwin terminal emulator such as
> MinTTY (I tried both and don't have UTF-16 output in neither of them, but
> this would still be useful to know when/if I debug this further)?
I use only MinTTY.
> AFAIK the only way to obtain UTF-16 output is to explicitly call
> _setmode() with _O_U16TEXT or _O_WTEXT from somewhere
[...]
> and lmi doesn't use _setmode() with neither _O_WTEXT nor _O_U16TEXT
> anywhere and wxFputs(), used for outputting the "NOTE:" string above, boils
> down to fputws() call, so I don't understand why does it work
> differently...
I searched thus:
git log -S _setmode
and the last change we made involving _setmode() was six years ago.
But I was sure we did something related to this recently...searching
again and omitting the leading underscore:
commit b47c9d49177f6a57863184929d63e69fba735bb7
Author: Gregory W. Chicares <address@hidden>
Date: Mon Aug 22 21:30:56 2016 +0000
Force standard output streams to binary mode
See:
http://lists.nongnu.org/archive/html/lmi/2016-08/msg00015.html
That change adds this code to a couple of main() functions:
+#if defined LMI_MSW
+ // Force standard output streams to binary mode.
+ setmode(fileno(stdout), O_BINARY);
+ setmode(fileno(stderr), O_BINARY);
+#endif // defined LMI_MSW
...which contains no _O_WTEXT or _O_U16TEXT.
> My only hope is that I've only tested with MSVC so far so perhaps there is
> an unsuspected difference between the (new) MinGW CRT behaviour and MSVC
> here. I will retest with MinGW later when I have a bit more time, but if
> this doesn't explain it, I don't really have any other hypothesis right
> now.
Perhaps MinGW-w64's setmode() sets wide characters by default, and
we need to write _O_U8TEXT explicitly? I'll try that tomorrow unless
you've already tried it.
- [lmi] UTF-16 output from automated GUI test?, Greg Chicares, 2016/10/19
- Re: [lmi] UTF-16 output from automated GUI test?, Vadim Zeitlin, 2016/10/19
- Re: [lmi] UTF-16 output from automated GUI test?,
Greg Chicares <=
- Re: [lmi] UTF-16 output from automated GUI test?, Vadim Zeitlin, 2016/10/20
- Re: [lmi] UTF-16 output from automated GUI test?, Greg Chicares, 2016/10/20
- Re: [lmi] UTF-16 output from automated GUI test?, Vadim Zeitlin, 2016/10/20
- Re: [lmi] UTF-16 output from automated GUI test?, Greg Chicares, 2016/10/20
- Re: [lmi] UTF-16 output from automated GUI test?, Vadim Zeitlin, 2016/10/20
- Re: [lmi] UTF-16 output from automated GUI test?, Greg Chicares, 2016/10/20
- Re: [lmi] UTF-16 output from automated GUI test?, Vadim Zeitlin, 2016/10/21
- Re: [lmi] UTF-16 output from automated GUI test?, Greg Chicares, 2016/10/20