Re: [lmi] UTF-16 output from automated GUI test?

[Greg Chicares]

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.