MinGW and Non-English Locale on Windows 7

classic Classic list List threaded Threaded
48 messages Options
123
Reply | Threaded
Open this post in threaded view
|

MinGW and Non-English Locale on Windows 7

Yongwei Wu
Hi gurus,

I think it started when I used GCC 4. When I input gcc on the command
line, I got something very weird:

gcc: ??óDê?è????t

My initial response was that GCC tried to output UTF-8 to a Chinese
command prompt. I simply dismissed the issue with "set LANG=en".

When I revisited this issue today, I found it was really very
different. I could not correct the output with iconv. I tried this and
wanted to check more carefully:

gcc 2> a.txt

To my great surprise, it contains the correct Chinese message that is
in the RIGHT encoding (CP936):

gcc: 没有输入文件 (the Chinese equivalent for "no input files")

I made some experiments. I found that if I treated it as Latin-1, it
was:

gcc: ûÓÐÊäÈëÎļþ

Now let us compare with the beginning error message again:

gcc: ??óDê?è????t

I noticed some something in common:

à --> ?
» --> ?
Ó --> ó
Ð --> D
Ê --> ê
ä --> ?
È --> è
ë --> ?
Î --> ?
Ä --> ?
¼ --> ?
þ --> t

Apparently the text is good somewhere, but treated as Latin-1 and
downgraded to Chinese-compatible characters when output to the screen
(but not when redirected to a file).

It did not took me long to get the wrong message with this test
program:

#include <locale.h>
#include <stdio.h>

char msg[] = "\303\273\323\320\312\344\310\353\316\304\274\376";

void Test1()
{
    printf("Test1: ");
    char* ptr = msg;
    while (*ptr) {
        putchar(*ptr);
        ++ptr;
    }
    putchar('\n');
}

void Test2()
{
    printf("Test2: ");
    puts(msg);
}

int main()
{
    Test1();
    Test2();
    setlocale(LC_CTYPE, "Chinese_China.936");
    Test1();
    Test2();
    setlocale(LC_CTYPE, "Chinese_China.1252");
    Test1();
    Test2();
}

I got:

Test1: 没有输入文件
Test2: 没有输入文件
Test1:
Test2: 没有输入文件
Test1: ??óDê?è????t
Test2: ??óDê?è????t

Since it was a surprise, I copied the resulting exe to an XP machine,
and it output the correct Chinese text on all six lines!

My regional settings have a few quirks, and basically
setlocale(LC_CTYPE, "") is equivalent to setlocale(LC_CTYPE,
"Chinese_China.1252"). Normal Windows 7 users are more likely to see
the setlocale(LC_CTYPE, "Chinese_China.936") result. I.e., they cannot
see the messages that are supposed to be Chinese at all.

I feel bad for my Chinese friends, and wish they all used Windows XP
or knew how to set LANG=en.

I am not familiar with the GCC source, and do not know how easy it is
to make a fix. Apparently, one of the following should be possible:

* Remove any use of setlocale(LC_ALL, "") or setlocale(LC_CTYPE, "").
* Add a setlocale(LC_CTYPE, "C") after setlocale(LC_ALL, ""). (BTW,
  this was actually a patch for Vim on Windows, to fix a related but
  different locale issue about multibyte characters.)
* Use printf or puts, but NOT putchar/putc/fputc. (With the last fix,
  I would still have the same problem, but most Chinese users would be
  more lucky.)

Any comments, gurus?

Oh, my GCC version is:

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/4.5.2/lto-wrapper.exe
Target: mingw32
Configured with: ../gcc-4.5.2/configure
--enable-languages=c,c++,ada,fortran,objc,obj-c++
--disable-sjlj-exceptions --with-dwarf2 --enable-shared
--enable-libgomp --disable-win32-registry --enable-libstdcxx-debug
--enable-version-specific-runtime-libs --disable-werror
--build=mingw32 --prefix=/mingw
Thread model: win32
gcc version 4.5.2 (GCC)

My OS version is Windows 7 Enterprise x64 Edition 6.1.7600.

Best regards,

Yongwei

--
Wu Yongwei
URL: http://wyw.dcweb.cn/

------------------------------------------------------------------------------
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
cg
Reply | Threaded
Open this post in threaded view
|

Re: MinGW and Non-English Locale on Windows 7

cg
On 2011-06-22 8:13 PM, Yongwei Wu wrote:

> Hi gurus,
>
> I think it started when I used GCC 4. When I input gcc on the command
> line, I got something very weird:
>
> gcc: ??óDê?è????t
>
> My initial response was that GCC tried to output UTF-8 to a Chinese
> command prompt. I simply dismissed the issue with "set LANG=en".
>

I remember it is documented somewhere that most GNU packages require
both LANG and LANGUAGE to be set to get pure English output.

Regards
cg


------------------------------------------------------------------------------
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: MinGW and Non-English Locale on Windows 7

Xiaofan Chen
On Thu, Jun 23, 2011 at 12:07 PM, cg <[hidden email]> wrote:

> On 2011-06-22 8:13 PM, Yongwei Wu wrote:
>> Hi gurus,
>>
>> I think it started when I used GCC 4. When I input gcc on the command
>> line, I got something very weird:
>>
>> gcc: ??óDê?è????t
>>
>> My initial response was that GCC tried to output UTF-8 to a Chinese
>> command prompt. I simply dismissed the issue with "set LANG=en".
>>
>
> I remember it is documented somewhere that most GNU packages require
> both LANG and LANGUAGE to be set to get pure English output.
>

I am not so sure about this.

But here is another example with regard to libtool and MinGW.
http://lists.gnu.org/archive/html/bug-libtool/2010-03/msg00002.html

I had this issue last time when I was trying to build libusb-1.0 with
MinGW and in the end it was a Locale issue for libtool under MinGW
as I was using English Windows but set the Locale to Chinese for
some non-unicode-compliant programs.
The bug was fixed later as seen in the above thread.

--
Xiaofan

------------------------------------------------------------------------------
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: MinGW and Non-English Locale on Windows 7

Yongwei Wu
In reply to this post by cg
On 23 June 2011 12:07, cg <[hidden email]> wrote:

> On 2011-06-22 8:13 PM, Yongwei Wu wrote:
>> Hi gurus,
>>
>> I think it started when I used GCC 4. When I input gcc on the command
>> line, I got something very weird:
>>
>> gcc: ??óDê?è????t
>>
>> My initial response was that GCC tried to output UTF-8 to a Chinese
>> command prompt. I simply dismissed the issue with "set LANG=en".
>>
>
> I remember it is documented somewhere that most GNU packages require
> both LANG and LANGUAGE to be set to get pure English output.

LANG alone works in this case, but that is not the point. If we should
always set the language to English, why localize then? :-)

My point is not to get English output, but highlight the fact that the
current GCC localization does not work on Windows 7 (at least not on
the 64-bit system; probably not on the 32-bit system either), and
provide some analysis so that other people who have more time and
initiative may actually work out a fix.

Best regards,

Yongwei

--
Wu Yongwei
URL: http://wyw.dcweb.cn/

------------------------------------------------------------------------------
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: MinGW and Non-English Locale on Windows 7

Earnie Boyd
Yongwei Wu wrote:
> My point is not to get English output, but highlight the fact that the
> current GCC localization does not work on Windows 7 (at least not on
> the 64-bit system; probably not on the 32-bit system either), and
> provide some analysis so that other people who have more time and
> initiative may actually work out a fix.

If you feel your issue warrants a fix then you should follow
http://www.mingw.org/Reporting_Bugs for reporting the bug.

--
Earnie
-- http://www.for-my-kids.com

------------------------------------------------------------------------------
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: MinGW and Non-English Locale on Windows 7

Yongwei Wu
On 23 June 2011 19:55, Earnie <[hidden email]> wrote:
> Yongwei Wu wrote:
>> My point is not to get English output, but highlight the fact that the
>> current GCC localization does not work on Windows 7 (at least not on
>> the 64-bit system; probably not on the 32-bit system either), and
>> provide some analysis so that other people who have more time and
>> initiative may actually work out a fix.
>
> If you feel your issue warrants a fix then you should follow
> http://www.mingw.org/Reporting_Bugs for reporting the bug.

Done.

https://sourceforge.net/tracker/?func=detail&aid=3325169&group_id=2435&atid=102435

I also added my concluded new rules to the bug report.

Best regards,

Yongwei

--
Wu Yongwei
URL: http://wyw.dcweb.cn/

------------------------------------------------------------------------------
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: MinGW and Non-English Locale on Windows 7

Charles Wilson-2
In reply to this post by Yongwei Wu
On 6/23/2011 1:03 AM, Yongwei Wu wrote:
> LANG alone works in this case, but that is not the point. If we should
> always set the language to English, why localize then? :-)

I agree.  Supporting non-english locales -- as best we can, given the
limitations of MSYS (*) -- was the whole point of rebuilding all of the
MSYS and many of the MinGW tools with libintl support.

> My point is not to get English output, but highlight the fact that the
> current GCC localization does not work on Windows 7 (at least not on
> the 64-bit system; probably not on the 32-bit system either), and
> provide some analysis so that other people who have more time and
> initiative may actually work out a fix.

Unfortunately I (a) don't have access to any WinOS beyond vista, and (b)
don't /really/ know enough about i18n issues to track this down - I just
know enough to be dangerous.

Anyway, modifying our tools to always 'setlocale(LC_CTYPE, "C")' just
seems counterproductive, a step backwards, to me.

(*) Even cygwin didn't add really GOOD support for i18n until 1.7; msys
is based on 1.3...However, there's got to be a reasonable fix that still
allows i18n, because nobody reported problems with cgywin-1.3 and the
cygwin gcc of that era -- which /was/ NLS-enabled.  OTOH, Win7 didn't
exist back then, either.

Yongwei Wu -- what /terminal/ are you using? There are several
alteratives that may affect your experience:
  * invoking gcc from a bash shell, running in a cmd.exe window?
  * invoking gcc from a bash shell, running in rxvt
  * invoking gcc from a bash shell, running in mintty
  * invoking gcc directly from within a cmd.exe window (no bash)
Try each of those and see if you get a better experience. I suspect the
mintty scenario might work better (be sure and use its options menu to
set the expected locale and character set).

--
Chuck

------------------------------------------------------------------------------
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: MinGW and Non-English Locale on Windows 7

Yongwei Wu
On 24 June 2011 00:54, Charles Wilson <[hidden email]> wrote:
> Anyway, modifying our tools to always 'setlocale(LC_CTYPE, "C")' just
> seems counterproductive, a step backwards, to me.

It might be the way to go, if the existing code does not conform to
the way Microsoft expects it, and it is too big a trouble to change
it. BTW, the consequences of calling setlocale (other than "C") is
often not well documented.

*Microsoft thinks if the locale is not "C", it will do some conversion
for you.* This may not be what programmers want, though I think
Microsoft has its rationales to do that.

This is at least the third time I was bitten by Microsoft surprises in
dealing with non-ASCII characters:

1) Microsoft does not allow passing a string that is "invalid" in the
current locale to the format string in *printf. One Vim crash was
caused by that and was later fixed by calling setlocale(LC_CTYPE,
"C").

2) Beginning in Visual Studio 2005, std::fstream has a dependency on
the locale when opening files that have non-ASCII characters in the
name. I resorted to the (non-standard) fstream::open(wchar_t)
interface to overcome that. MinGW does not support this form.

3) Now I see that incomplete characters cannot be output to the
console (but still OK for the files). And Microsoft converts the
characters from the locale to the console code page for you.

> (*) Even cygwin didn't add really GOOD support for i18n until 1.7; msys
> is based on 1.3...However, there's got to be a reasonable fix that still
> allows i18n, because nobody reported problems with cgywin-1.3 and the
> cygwin gcc of that era -- which /was/ NLS-enabled.  OTOH, Win7 didn't
> exist back then, either.

It has nothing to do with MSYS, since I am not using it.

> Yongwei Wu -- what /terminal/ are you using? There are several
> alteratives that may affect your experience:
>  * invoking gcc from a bash shell, running in a cmd.exe window?

The same as using the Command Prompt without bash (Cygwin).

>  * invoking gcc from a bash shell, running in rxvt

As expected, characters are correct. Rxvt (Cygwin) is I/O redirection,
as far as MSVCRT is concerned.

>  * invoking gcc from a bash shell, running in mintty

No experience.  I assume it is the same as rxvt.

>  * invoking gcc directly from within a cmd.exe window (no bash)

This is what I use, and has the described behaviour.


Best regards,

Yongwei

--
Wu Yongwei
URL: http://wyw.dcweb.cn/

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense..
http://p.sf.net/sfu/splunk-d2d-c1
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: MinGW and Non-English Locale on Windows 7

Yongwei Wu
On 24 June 2011 16:17, Yongwei Wu <[hidden email]> wrote:
> 1) Microsoft does not allow passing a string that is "invalid" in the
> current locale to the format string in *printf. One Vim crash was
> caused by that and was later fixed by calling setlocale(LC_CTYPE,
> "C").

I would like to explain this issue a little more, since I suspect
other people may make the same mistake.

Vim has something like this for some sprintf (or similar) calls,
"Error %d in file %s blah". The format strings are sometimes in UTF-8.
This causes problems, since UTF-8 is not valid for the
locale--Microsoft only allow one- or two-byte characters in its
MBCS-aware code (*printf is among them). Because "%" may be a valid
second-byte in a multi-byte character, Microsoft (rightfully) checks
the format string against the locale. The problem occurs when there is
an odd number of consecutive bytes at the end of the format string
(frequent enough for UTF-8) and the locale is DBCS (Chinese, Japanese,
Korean, etc.): the check see that a byte is bigger than 0x80 and
happily skips over the next byte, which can actually be \0. The end of
string is passed, and you know what could happen next.

Bram decided it was not worth while to make the format string valid in
the current locale, and a setlocale(LC_CTYPE, "C") calmed the world.
No one complained of this change ever since.

Best regards,

Yongwei

--
Wu Yongwei
URL: http://wyw.dcweb.cn/

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense..
http://p.sf.net/sfu/splunk-d2d-c1
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: MinGW and Non-English Locale on Windows 7

dashesy
On Fri, Jun 24, 2011 at 2:39 AM, Yongwei Wu <[hidden email]> wrote:

> On 24 June 2011 16:17, Yongwei Wu <[hidden email]> wrote:
>> 1) Microsoft does not allow passing a string that is "invalid" in the
>> current locale to the format string in *printf. One Vim crash was
>> caused by that and was later fixed by calling setlocale(LC_CTYPE,
>> "C").
>
> I would like to explain this issue a little more, since I suspect
> other people may make the same mistake.
>
> Vim has something like this for some sprintf (or similar) calls,
> "Error %d in file %s blah". The format strings are sometimes in UTF-8.
> This causes problems, since UTF-8 is not valid for the
> locale--Microsoft only allow one- or two-byte characters in its
> MBCS-aware code (*printf is among them). Because "%" may be a valid
> second-byte in a multi-byte character, Microsoft (rightfully) checks
> the format string against the locale. The problem occurs when there is
> an odd number of consecutive bytes at the end of the format string
> (frequent enough for UTF-8) and the locale is DBCS (Chinese, Japanese,
> Korean, etc.): the check see that a byte is bigger than 0x80 and
> happily skips over the next byte, which can actually be \0. The end of
> string is passed, and you know what could happen next.
Just as a suggestion, can you always append one byte at the end of the
format string with \0, when you are expecting anything other than
ASCII?

>
> Bram decided it was not worth while to make the format string valid in
> the current locale, and a setlocale(LC_CTYPE, "C") calmed the world.
> No one complained of this change ever since.
>
> Best regards,
>
> Yongwei
>
> --
> Wu Yongwei
> URL: http://wyw.dcweb.cn/
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense..
> http://p.sf.net/sfu/splunk-d2d-c1
> _______________________________________________
> MinGW-users mailing list
> [hidden email]
>
> This list observes the Etiquette found at
> http://www.mingw.org/Mailing_Lists.
> We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.
>
> _______________________________________________
> You may change your MinGW Account Options or unsubscribe at:
> https://lists.sourceforge.net/lists/listinfo/mingw-users
> Also: mailto:[hidden email]?subject=unsubscribe
>
dashesy

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense..
http://p.sf.net/sfu/splunk-d2d-c1
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: MinGW and Non-English Locale on Windows 7

Charles Wilson-2
In reply to this post by Yongwei Wu
On 6/24/2011 4:17 AM, Yongwei Wu wrote:

> On 24 June 2011 00:54, Charles Wilson <[hidden email]> wrote:
>> Anyway, modifying our tools to always 'setlocale(LC_CTYPE, "C")' just
>> seems counterproductive, a step backwards, to me.
>
> It might be the way to go, if the existing code does not conform to
> the way Microsoft expects it, and it is too big a trouble to change
> it. BTW, the consequences of calling setlocale (other than "C") is
> often not well documented.
>
> *Microsoft thinks if the locale is not "C", it will do some conversion
> for you.* This may not be what programmers want, though I think
> Microsoft has its rationales to do that.

How..."nice"...of Microsoft.  And typical -- to assume they know best.

> This is at least the third time I was bitten by Microsoft surprises in
> dealing with non-ASCII characters:
>
> 1) Microsoft does not allow passing a string that is "invalid" in the
> current locale to the format string in *printf. One Vim crash was
> caused by that and was later fixed by calling setlocale(LC_CTYPE,
> "C").

OK, this affects MinGW (*) programs only, since MSYS applications have
their own implementation of all of the *printf functions.

(*) But...if you build the MinGW application with
-D__USE_MINGW_ANSI_STDIO, then you get an independent implementation of
the printf functions.  Dunno if that would *help* in this case -- I
doubt our libmingwex.a implementation is multibyte aware. It probably
just interprets them as single-byte strings.

What happens if you compile your test program with -D__USE_MINGW_ANSI_STDIO?

> 2) Beginning in Visual Studio 2005, std::fstream has a dependency on
> the locale when opening files that have non-ASCII characters in the
> name. I resorted to the (non-standard) fstream::open(wchar_t)
> interface to overcome that. MinGW does not support this form.

But stuff compiled using mingw does not use the msvcrt71 runtime (**)
that is part of VS2005.  MinGW-compiled stuff uses plain old msvcrt.dll.

(**) Well, it doesn't unless you do a lot of work to make that happen.

> 3) Now I see that incomplete characters cannot be output to the
> console (but still OK for the files). And Microsoft converts the
> characters from the locale to the console code page for you.

But the problem, as I see it, is a mismatch between two *different*
non-C locales, right?  Plus the fact that the msvcrt setlocale(*, "")
function does not respect environment variables.

There is a gnulib module that is intended to fix this, specifically for
mingw, just introduced earlier this year.

http://lists.gnu.org/archive/html/bug-gnulib/2011-02/msg00154.html

Perhaps we should look into importing this setlocale replacement into
*all* i18n-capable mingw apps we provide. (We can't add it to libmingwex
because it's LGPL, not public domain.  For simplicitly, we could ship a
simple LGPL .a in a mingw-libsetlocale package that provides this
module, and then add it to the LDFLAGS of other mingw packages...)

>> (*) Even cygwin didn't add really GOOD support for i18n until 1.7; msys
>> is based on 1.3...However, there's got to be a reasonable fix that still
>> allows i18n, because nobody reported problems with cgywin-1.3 and the
>> cygwin gcc of that era -- which /was/ NLS-enabled.  OTOH, Win7 didn't
>> exist back then, either.
>
> It has nothing to do with MSYS, since I am not using it.

I see that now.

>> Yongwei Wu -- what /terminal/ are you using? There are several
>> alteratives that may affect your experience:
>>  * invoking gcc from a bash shell, running in a cmd.exe window?
>
> The same as using the Command Prompt without bash (Cygwin).
>
>>  * invoking gcc from a bash shell, running in rxvt
>
> As expected, characters are correct. Rxvt (Cygwin) is I/O redirection,
> as far as MSVCRT is concerned.
>
>>  * invoking gcc from a bash shell, running in mintty
>
> No experience.  I assume it is the same as rxvt.

Actually, no.  rxvt is ancient, dead, and buried, and has ZERO support
for codepages, charsets, or i18n of any kind.  mintty has a lot of
modern win32-native support for such things.

>
>>  * invoking gcc directly from within a cmd.exe window (no bash)
>
> This is what I use, and has the described behaviour.

Well, that's certainly the simplest case.

However, the effect of using cygwin-bash is probably much different than
using msys-bash, so I would not consider them interchangeable.

For now, tho, we should concentrate on fixing the simple problem: mingw
exe's running in plain old cmd.exe with no bash at all.

--
Chuck

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense..
http://p.sf.net/sfu/splunk-d2d-c1
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: MinGW and Non-English Locale on Windows 7

Yongwei Wu
In reply to this post by dashesy
On 25 June 2011 00:24, dashesy <[hidden email]> wrote:

> On Fri, Jun 24, 2011 at 2:39 AM, Yongwei Wu <[hidden email]> wrote:
>> On 24 June 2011 16:17, Yongwei Wu <[hidden email]> wrote:
>>> 1) Microsoft does not allow passing a string that is "invalid" in the
>>> current locale to the format string in *printf. One Vim crash was
>>> caused by that and was later fixed by calling setlocale(LC_CTYPE,
>>> "C").
>>
>> I would like to explain this issue a little more, since I suspect
>> other people may make the same mistake.
>>
>> Vim has something like this for some sprintf (or similar) calls,
>> "Error %d in file %s blah". The format strings are sometimes in UTF-8.
>> This causes problems, since UTF-8 is not valid for the
>> locale--Microsoft only allow one- or two-byte characters in its
>> MBCS-aware code (*printf is among them). Because "%" may be a valid
>> second-byte in a multi-byte character, Microsoft (rightfully) checks
>> the format string against the locale. The problem occurs when there is
>> an odd number of consecutive bytes at the end of the format string
>> (frequent enough for UTF-8) and the locale is DBCS (Chinese, Japanese,
>> Korean, etc.): the check see that a byte is bigger than 0x80 and
>> happily skips over the next byte, which can actually be \0. The end of
>> string is passed, and you know what could happen next.
> Just as a suggestion, can you always append one byte at the end of the
> format string with \0, when you are expecting anything other than
> ASCII?

Yes, according to the current code I have seen. No, according to
aesthetics and the future surprises Microsoft may give. Locale "C" is
good and gives no surprises.

--
Wu Yongwei
URL: http://wyw.dcweb.cn/

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense..
http://p.sf.net/sfu/splunk-d2d-c1
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: MinGW and Non-English Locale on Windows 7

Yongwei Wu
In reply to this post by Charles Wilson-2
On 25 June 2011 03:58, Charles Wilson <[hidden email]> wrote:
> On 6/24/2011 4:17 AM, Yongwei Wu wrote:
> (*) But...if you build the MinGW application with
> -D__USE_MINGW_ANSI_STDIO, then you get an independent implementation of
> the printf functions.  Dunno if that would *help* in this case -- I
> doubt our libmingwex.a implementation is multibyte aware. It probably
> just interprets them as single-byte strings.
>
> What happens if you compile your test program with -D__USE_MINGW_ANSI_STDIO?

My test program is not about using UTF-8 in printf, so it has nothing
to do with this issue.  The exe compiled with -D__USE_MINGW_ANSI_STDIO
no longer has dependency on printf in msvcrt.dll, but still uses
putchar, which is the current issue we are talking about.

>> 2) Beginning in Visual Studio 2005, std::fstream has a dependency on
>> the locale when opening files that have non-ASCII characters in the
>> name. I resorted to the (non-standard) fstream::open(wchar_t)
>> interface to overcome that. MinGW does not support this form.
>
> But stuff compiled using mingw does not use the msvcrt71 runtime (**)
> that is part of VS2005.  MinGW-compiled stuff uses plain old msvcrt.dll.

It is not a MinGW issue. I was just talking about Microsoft surprises
and code incompatibility it causes (simplistic code pieces that work
with MSVC no longer works with MinGW). Of course, I have my C++
wrapper to deal with it--something I love about C++. Pure C
incompatibility would be uglier to deal with in code.

> (**) Well, it doesn't unless you do a lot of work to make that happen.
>
>> 3) Now I see that incomplete characters cannot be output to the
>> console (but still OK for the files). And Microsoft converts the
>> characters from the locale to the console code page for you.
>
> But the problem, as I see it, is a mismatch between two *different*
> non-C locales, right?  Plus the fact that the msvcrt setlocale(*, "")
> function does not respect environment variables.

No, the major problem currently is that putchar no longer works for
Chinese characters.

setlocale(*, "") does not use environment variables. On a standard
Chinese Windows 7, it sets the program locale to the system locale
(normally "Chinese_China.936"), and then it has two impacts:

1) It converts characters from the locale to the console code page
(smaller one; no impact to most people).
2) It disallows Chinese characters to be output byte by byte with
putchar familily: you have to output the two bytes in a Chinese
character together (the bigger problem we have).

>>>  * invoking gcc from a bash shell, running in rxvt
>>
>> As expected, characters are correct. Rxvt (Cygwin) is I/O redirection,
>> as far as MSVCRT is concerned.
>>
>>>  * invoking gcc from a bash shell, running in mintty
>>
>> No experience.  I assume it is the same as rxvt.
>
> Actually, no.  rxvt is ancient, dead, and buried, and has ZERO support
> for codepages, charsets, or i18n of any kind.  mintty has a lot of
> modern win32-native support for such things.

It probably does matter. The major difference is that if the output is
not the console, the I/O functions don't do any conversions, which
does not surprise anybody.

>>>  * invoking gcc directly from within a cmd.exe window (no bash)
>>
>> This is what I use, and has the described behaviour.
>
> Well, that's certainly the simplest case.
>
> However, the effect of using cygwin-bash is probably much different than
> using msys-bash, so I would not consider them interchangeable.

As I mentioned, the difference is simply whether you use the console
or not use the console. So I do not think there is a difference
between cygwin-bash and msys-bash, if the console is used in both
cases.

> For now, tho, we should concentrate on fixing the simple problem: mingw
> exe's running in plain old cmd.exe with no bash at all.

This I agree.

Best regards,

Yongwei

--
Wu Yongwei
URL: http://wyw.dcweb.cn/

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense..
http://p.sf.net/sfu/splunk-d2d-c1
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: MinGW and Non-English Locale on Windows 7

Ross Ridge
In reply to this post by Yongwei Wu
Yongwei Wu writes:
>1) It converts characters from the locale to the console code page
>(smaller one; no impact to most people).

Actually, I believe what you're seeing is it converting from the
console or system code page to the font selected for the command window.
This is arguably more correct than the Windows XP behavior which was to
substitute another font for characters that weren't representable in the
selected font.  It would often select a non-constant width font and end
up looking a mess.

>2) It disallows Chinese characters to be output byte by byte with
>putchar familily: you have to output the two bytes in a Chinese
>character together (the bigger problem we have).

This is definately broken.  Can you reproduce it with Microsoft's
compilers?  Does using "(putchar)(c);" to avoid macro expansion solve
the problem?

                                        Ross Ridge


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense..
http://p.sf.net/sfu/splunk-d2d-c1
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: MinGW and Non-English Locale on Windows 7

Yongwei Wu
On 25 June 2011 12:58, Ross Ridge <[hidden email]> wrote:

> Yongwei Wu writes:
>>1) It converts characters from the locale to the console code page
>>(smaller one; no impact to most people).
>
> Actually, I believe what you're seeing is it converting from the
> console or system code page to the font selected for the command window.
> This is arguably more correct than the Windows XP behavior which was to
> substitute another font for characters that weren't representable in the
> selected font.  It would often select a non-constant width font and end
> up looking a mess.

I am not arguing that it is incorrect.  As I said, Microsoft has a rationale.

>>2) It disallows Chinese characters to be output byte by byte with
>>putchar familily: you have to output the two bytes in a Chinese
>>character together (the bigger problem we have).
>
> This is definately broken.  Can you reproduce it with Microsoft's
> compilers?  Does using "(putchar)(c);" to avoid macro expansion solve
> the problem?

Actually it is very complicated. Maybe you can see the reason from the
dates of the DLL files:

19/02/2011  00:40           773,968 msvcr100.dll
05/01/2002  11:37           344,064 msvcr70.dll
14/07/2009  09:15           690,688 msvcrt.dll
14/07/2009  09:11           836,608 kernel32.dll

The VC 2003 and VC 2010 DLLs are from the compiler, but the MSVCRT.DLL
is from the operating system (having the same date as kernel32.dll,
and also the same version 7.0.7600.16385).

VC 2003 gives (like XP):

Test1: 没有输入文件
Test2: 没有输入文件
Test1: 没有输入文件
Test2: 没有输入文件
Test1: 没有输入文件
Test2: 没有输入文件

VC 2010 gives something slightly different (having issue 1 but NOT 2!):

Test1: 没有输入文件
Test2: 没有输入文件
Test1: 没有输入文件
Test2: 没有输入文件
Test1: ??óDê?è????t
Test2: ??óDê?è????t

I've check the assembly code of the test program, and can confirm it
has this line:

call _putchar

So it is not a macro expansion problem. In fact, I think macro
expansion may result in better output....

Thinking the other way: if putchar() always outputs the character to
the screen immediately, it DOES fail with double-byte characters.

Best regards,

Yongwei

--
Wu Yongwei
URL: http://wyw.dcweb.cn/

------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: MinGW and Non-English Locale on Windows 7

Yongwei Wu
2011/6/26 Yongwei Wu <[hidden email]>:
> Thinking the other way: if putchar() always outputs the character to
> the screen immediately, it DOES fail with double-byte characters.

A quick test result. With either MinGW, VC 2003, or VC 2010, putchar
output the character without any buffering on my machine. So it seems
the 2003 and 2010 VC runtime can cache the half-character from the
caller, while the MSVCRT shipped with Windows 7 does something simple
and naive.

Best regards,

Yongwei

--
Wu Yongwei
URL: http://wyw.dcweb.cn/

------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: MinGW and Non-English Locale on Windows 7

Keith Marshall
In reply to this post by Charles Wilson-2
On 24/06/11 20:58, Charles Wilson wrote:
> OK, this affects MinGW (*) programs only, since MSYS applications have
> their own implementation of all of the *printf functions.
>
> (*) But...if you build the MinGW application with
> -D__USE_MINGW_ANSI_STDIO, then you get an independent implementation of
> the printf functions.  Dunno if that would *help* in this case -- I
> doubt our libmingwex.a implementation is multibyte aware.

Actually, it is, at least in so far as it will interpret the "%C" and
"%S% format conversion specs, (or their lower case equivalents with the
lower case ell modifier, "%lc" and "%ls"), converting the corresponding
wchar_t arguments to multibyte sequences, as appropriate to the active
locale.  In addition, it emits the radix point as specified in this
locale, when formatting floating point numerical arguments.

> It probably just interprets them as single-byte strings.

Yes, in the case of the format string, it does this.  That's something
we could look into changing, e.g. by transforming to the wchar_t domain
and scanning in that; at least that way, we would avoid the possibility
of misinterpreting "%" as a conversion spec introducer, where it occurs
as a trailing byte in a multibyte character sequence.

In the case of any other argument, such as a single "int" argument
interpreted through a "%c" conversion spec, or a "char *" argument
interpreted through "%s", there should be no issue.  Whether the
argument is strictly single-byte or (a participant in) a multibyte
sequence is immaterial; printf() simply emits it verbatim, leaving it to
the output device driver to interpret it as necessary.

Of course, none of the foregoing addresses the issue if Microsoft's
printf() implementation is deployed; even if the MinGW implementation
is involved, it is relevant only if the issue arises as a result of
misinterpretation of the format argument.

--
Regards,
Keith.

------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: MinGW and Non-English Locale on Windows 7

Keith Marshall
In reply to this post by Yongwei Wu
On 25/06/11 04:22, Yongwei Wu wrote:

> On 25 June 2011 03:58, Charles Wilson wrote:
>> On 6/24/2011 4:17 AM, Yongwei Wu wrote:
>> (*) But...if you build the MinGW application with
>> -D__USE_MINGW_ANSI_STDIO, then you get an independent implementation of
>> the printf functions.  Dunno if that would *help* in this case -- I
>> doubt our libmingwex.a implementation is multibyte aware. It probably
>> just interprets them as single-byte strings.
>>
>> What happens if you compile your test program with -D__USE_MINGW_ANSI_STDIO?
>
> My test program is not about using UTF-8 in printf,

Chuck didn't mention UTF-8; what makes you believe that we think it to
have any bearing on the issue?

> so it has nothing
> to do with this issue.  The exe compiled with -D__USE_MINGW_ANSI_STDIO
> no longer has dependency on printf in msvcrt.dll, but still uses
> putchar, which is the current issue we are talking about.

Well, putchar() is strictly an 8-bit single byte output mechanism, but
even when emitting multibyte sequences, that's completely irrelevant; a
multibyte sequence emitted one byte at a time via putchar() should still
be interpreted correctly by the device driver receiving it.  If it
isn't, and the device locale matches the locale for which the
application has encoded the output stream, then the device driver is
broken.  You've stated elsewhere in this thread, that the byte sequences
appear to be correct, when redirected to a file.  This suggests that either:

- The locale selected in the application, by setlocale( LC_CTYPE, "" ),
does not match the locale configured for the device driver, or

- the device driver mishandles the multibyte sequences which are
appropriate in its configured locale encoding.

I don't see how either of these is a MinGW issue. [*]

[*] However, see my reply to Chuck's preceding message, which does
identify a potential MinGW issue, albeit one which you seem to want to
dismiss out of hand; (admittedly, it may not be strictly relevant to
this particular issue, but it still merits attention).

--
Regards,
Keith.

------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: MinGW and Non-English Locale on Windows 7

Keith Marshall
On 27/06/11 12:38, Keith Marshall wrote:

> You've stated elsewhere in this thread, that the byte sequences
> appear to be correct, when redirected to a file.  This suggests that either:
>
> - The locale selected in the application, by setlocale( LC_CTYPE, "" ),
> does not match the locale configured for the device driver, or
>
> - the device driver mishandles the multibyte sequences which are
> appropriate in its configured locale encoding.
>
> I don't see how either of these is a MinGW issue.

A third (application level) possibility, which *could* be a MinGW issue:

- The application binds a message catalogue which is not appropriate for
the locale selected by setlocale( LC_CTYPE, "" )

However, in this case we would hardly expect to see correct byte
sequences when redirecting output to files, so this seems less likely.

--
Regards,
Keith.

------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: MinGW and Non-English Locale on Windows 7

Charles Wilson-2
In reply to this post by Keith Marshall
On 6/27/2011 7:38 AM, Keith Marshall wrote:
> - The locale selected in the application, by setlocale( LC_CTYPE, "" ),
> does not match the locale configured for the device driver, or

And this is the issue that Bruno's setlocale() implementation in gnulib
is intended to address, IIUC.  The "device driver" -- in this case,
conhost.exe (W7+) or cmd.exe (Vista-) -- gets its locale, by default,
from the Windows i18n settings, NOT from any env var.  Now, mintty
allows to *explicitly* set the locale via a drop down menu, independent
of the overall win32 locale settings; mintty also forwards that value
via the LC_* and LANG env vars to its inferior shell (that is, msys- or
cygwin-bash).


However, many unix apps ported to win32 explicitly check the env for
%LC_*% or %LANG%, but then setlocale() doesn't do what is expected (this
is actually more of an issue when invoking mingw apps from inside a
unixy shell -- cygwin, msys, interix, or nutc -- where such env vars ARE
typically set to something. So in this case, it's easy to end up with a
mismatch between what those env var values are, and what the (dumb,
default) setlocale(LC_CTYPE, "") does.

Bruno's (re)implementation checks the env var first, and uses those to
override whatever the system settings are, when setlocale is called with "".

--
Chuck

------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
123