lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Vadim Zeitlin
Subject: Re: [lmi] UTF-16 output from automated GUI test?
Date: Thu, 20 Oct 2016 01:24:23 +0200

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)?

 AFAIK the only way to obtain UTF-16 output is to explicitly call
_setmode() with _O_U16TEXT or _O_WTEXT from somewhere and, indeed, if I
compile and run this program:
---------------------------------- >8 --------------------------------------
#include <fcntl.h>
#include <io.h>
#include <stdio.h>
#include <wchar.h>

int main()
{
    _setmode(_fileno(stdout), _O_WTEXT);
    return fputws(L"Hello, world!\n", stdout);
}
---------------------------------- >8 --------------------------------------
I do get UTF-16 output, but without the _setmode() call I get normal ASCII
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...

 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.

 Regards,
VZ


reply via email to

[Prev in Thread] Current Thread [Next in Thread]