Perl / perl5

🐪 The Perl programming language
https://dev.perl.org/perl5/
Other
1.9k stars 540 forks source link

run/locale.t fails all tests on Win32 #13562

Closed p5pRT closed 10 years ago

p5pRT commented 10 years ago

Migrated from rt.perl.org#121106 (status was 'resolved')

Searchable as RT121106$

p5pRT commented 10 years ago

From @bulk88

Created by @bulk88

Some time in the last couple days this test on blead started failing on me. WinXP\, 32 bit\, VC 2003.

------------------------------------------------------------------ Test Summary Report ------------------- run/locale.t (Wstat​: 0 Tests​:   16 Failed​: 16)   Failed tests​: 1-16 Files=2402\, Tests=694552\, 2421 wallclock secs (77.34 usr + 4.25 sys = 81.59 CPU ) Result​: FAIL NMAKE : fatal error U1077​: '..\perl.exe' : return code '0x10' Stop.

C​:\perl519\src\win32> ------------------------------------------------------------------

http​://perl5.git.perl.org/perl.git/commit/d369fd5b026662cae636af9907037fdd15fc4adb maybe this is related?

----------------------------------------------------------------- C​:\perl519\src\t>..\perl -I..\lib harness run/locale.t run/locale.t .. # Failed test 1 - no locales where LC_NUMERIC breaks at ./test.p l line 954 # got undef # expected "" # PROG​: # for (qw(Afrikaans Albanian American Basque Bulgarian C Croatian Czech Danish D utch English Estonian Finnish Galician German Greek Hungarian Indonesian Italian   Latvian Lithuanian Norwegian Polish Russian Serbian Slovak Slovenian Swedish Tu rkish Welsh af da en fi fy ga hu it la mo no no\@​nynorsk ro ru sl)) { # use POSIX qw(locale_h); # use locale; # setlocale(LC_NUMERIC\, "$_") or next; # my $s = sprintf "%g %g"\, 3.1\, 3.1; # next if $s eq '3.1 3.1' || $s =~ /^(3.+1) \1$/; # print "$_ $s\n"; # } # STATUS​: -1 # Failed test 2 - LC_NUMERIC without environment nor setlocale() has no effect i n any locale at ./test.pl line 954 # got undef run/locale.t .. 1/16 # expected "" # PROG​: # for (qw(Afrikaans Albanian American Basque Bulgarian C Croatian Czech Danish D utch English Estonian Finnish Galician German Greek Hungarian Indonesian Italian   Latvian Lithuanian Norwegian Polish Russian Serbian Slovak Slovenian Swedish Tu rkish Welsh af da en fi fy ga hu it la mo no no\@​nynorsk ro ru sl)) { # use POSIX qw(locale_h); # use locale; # my $in = 4.2; # my $s = sprintf "%g"\, $in; # avoid any constant folding bugs # next if $s eq "4.2"; # print "$_ $s\n"; # } # STATUS​: -1 # Failed test 3 - format() does not look at LC_NUMERIC without 'use locale' at . /test.pl line 954 # got undef # expected "4.2" # PROG​: # format STDOUT = # @​.# # 4.179 # . # write; # STATUS​: -1 # Failed test 4 - format() looks at LC_NUMERIC with 'use locale' at ./test.pl li ne 954 # got undef # expected "4\,2" # PROG​: # use locale; # format STDOUT = # @​.# # 4.179 # . # write; # STATUS​: -1 # Failed test 5 - format() looks at LC_NUMERIC with 'use locale "​:not_characters "' at ./test.pl line 954 # got undef # expected "4\,2" # PROG​: # use locale "​:not_characters"; # format STDOUT = # @​.# # 4.179 # . # write; # STATUS​: -1 # Failed test 6 - too late to look at the locale at write() time at ./test.pl li ne 954 # got undef # expected "4.2" # PROG​: # format STDOUT = # @​.# # 4.179 # . # { require locale; import locale; write; } # STATUS​: -1 # Failed test 7 - too late to ignore the locale at write() time at ./test.pl lin e 954 # got undef # expected "4\,2" # PROG​: # use locale; # format STDOUT = # @​.# # 4.179 # . # { no locale; write; } # STATUS​: -1 # Failed test 8 - version does not clobber version at ./test.pl line 954 # got undef # expected "" # PROG​: # BEGIN { # if("define") { # require locale; import locale; # } # } # use POSIX; # my $i = 0.123; # POSIX​::setlocale(POSIX​::LC_NUMERIC()\,"Albanian"); # $a = sprintf("%.2f"\, $i); # require version; # $b = sprintf("%.2f"\, $i); # print ".$a $b" unless $a eq $b # STATUS​: -1 # Failed test 9 - version does not clobber version (via eval) at ./test.pl line 954 # got undef # expected "" # PROG​: # use locale; # use POSIX; # my $i = 0.123; # POSIX​::setlocale(POSIX​::LC_NUMERIC()\,"Albanian"); # $a = sprintf("%.2f"\, $i); # eval "use v5.0.0"; # $b = sprintf("%.2f"\, $i); # print "$a $b" unless $a eq $b # STATUS​: -1 # Failed test 10 - sprintf() and printf() look at LC_NUMERIC regardless of const ant folding at ./test.pl line 954 # got undef # expected "4\,2 4\,2 4\,2 4\,2 " # PROG​: # use locale; # use POSIX qw(locale_h); # setlocale(LC_NUMERIC\, ""); # my $in = 4.2; # printf("%g %g %s %s "\, $in\, 4.2\, sprintf("%g"\, $in)\, sprintf("%g"\, 4 .2)); # STATUS​: -1 # Failed test 11 - No compile error on v-strings when setting the locale to non- dot radix at compile time when default environment has non-dot radix at ./test.p l line 954 # got undef # expected "C" # PROG​: # use POSIX qw(locale_h); # # BEGIN { setlocale(LC_NUMERIC\, "Albanian"); }; # setlocale(LC_ALL\, "C"); # use 5.008; # print setlocale(LC_NUMERIC); # STATUS​: -1 # Failed test 12 - Passed in LC_NUMERIC is valid at compilation time at ./test.p l line 954 # got undef # expected "Albanian" # PROG​: # use POSIX qw(locale_h); # # BEGIN { print setlocale(LC_NUMERIC)\, " # "; }; # STATUS​: -1 # Failed test 13 - Radix print properly in locale scope\, and without at ./test.p l line 954 # got undef # expected "1\,5\n1.5" # PROG​: # my $i = 1.5; # { # use locale; # use POSIX; # POSIX​::setlocale(POSIX​::LC_NUMERIC()\,"Albanian"); # print $i\, " # "; # } # print $i\, " # "; # STATUS​: -1 # Failed test 14 - Can do math when radix is a comma at ./test.pl line 954 # got undef # expected "1\,5\n2\,5" # PROG​: # my $i = 1.5; # Should be exactly representable as a base 2 # # fraction\, so can use 'eq' below # use locale; # use POSIX; # POSIX​::setlocale(POSIX​::LC_NUMERIC()\,"Albanian"); # print $i\, " # "; # $i += 1; # print $i\, " # "; # STATUS​: -1 # Failed test 15 - POSIX​::strtod() uses underlying locale at ./test.pl line 954 # got undef # expected "1.5" # PROG​: # use POSIX; # POSIX​::setlocale(POSIX​::LC_NUMERIC()\,"Albanian"); # my $one_point_5 = POSIX​::strtod("1\,5"); # $one_point_5 =~ s/0+$//; # Remove any trailing zeros # print $one_point_5\, " # "; # STATUS​: -1 # Failed test 16 - /il matching of [bracketed] doesn't skip POSIX class if fails   individ char at ./test.pl line 954 # got undef # expected "1" # PROG​: # use locale; # use POSIX; # POSIX​::setlocale(POSIX​::LC_CTYPE()\,"C"); # print "h" =~ /[g\w]/i || 0; # print "\n"; # STATUS​: -1 run/locale.t .. Failed 16/16 subtests

Test Summary Report ------------------- run/locale.t (Wstat​: 0 Tests​: 16 Failed​: 16)   Failed tests​: 1-16 Files=1\, Tests=16\, 1 wallclock secs ( 0.03 usr + 0.00 sys = 0.03 CPU) Result​: FAIL

C​:\perl519\src\t> ----------------------------------------------------------------- C​:\perl519\src\t>git log -n 4 WARNING​: terminal is not fully functional commit c02d66974dbe736ac96e0ee464b2ee7948935ffe Author​: Daniel Dragan \bulk88@​hotmail\.com Date​: Fri Jan 10 16​:32​:37 2014 -0500

  b88 bld

commit fb29cc72fe9ef39100123477fffae4fad34866b7 Author​: Karl Williamson \public@​khwilliamson\.com Date​: Mon Jan 27 22​:42​:25 2014 -0700

  regcomp.c​: Change a variable and flag bit names

  The meaning of these was expanded two commits ago\, so update the name to   reflect this\, to prevent future confusion

commit baa60164aa329dbdc2e418a7743d51a081db237e Author​: Karl Williamson \public@​khwilliamson\.com Date​: Mon Jan 27 22​:30​:29 2014 -0700

  White-space\, comments only

  This mostly indents and outdents base on blocks added or removed by the   previous commit. But there are a few comment changes and vertical   alignment of macro backslash continuation characters\, and other   white-space changes : commit 31f05a37c4e9c37a7263491f2fc0237d836e1a80 Author​: Karl Williamson \public@​khwilliamson\.com Date​: Mon Jan 27 15​:35​:00 2014 -0700

  Work properly under UTF-8 LC_CTYPE locales

  This large (sorry\, I couldn't figure out how to meaningfully split it   up) commit causes Perl to fully support LC_CTYPE operations (case   changing\, character classification) in UTF-8 locales.

  As a side effect it resolves [perl #56820].

  The basics are easy\, but there were a lot of details\, and one   troublesome edge case discussed below.

  What essentially happens is that when the locale is changed to a UTF-8   one\, a global variable is set TRUE (FALSE when changed to a non-UTF-8   locale). Within the scope of 'use locale'\, this variable is checked\,   and if TRUE\, the code that Perl uses for non-locale behavior is used   instead of the code for locale behavior. Since Perl's internal   representation is UTF-8\, we get UTF-8 behavior for a UTF-8 locale.

  More work had to be done for regular expressions. There are three   cases.

  1) The character classes \w\, [[​:punct​:]] needed no extra work\, as   the changes fall out from the base work.

  2) Strings that are to be matched case-insensitively. These form   EXACTFL regops (nodes). Notice that if such a string contains only   characters above-Latin1 that match only themselves\, that the node can be   downgraded to an EXACT-only node\, which presents better optimization   possibilities\, as we now have a fixed string known at compile time to be   required to be in the target string to match. Similarly if all   characters in the string match only other above-Latin1 characters   case-insensitively\, the node can be downgraded to a regular EXACTFU node   (match\, folding\, using Unicode\, not locale\, rules). The code changes   for this could be done without accepting UTF-8 locales fully\, but there   were edge cases which needed to be handled differently if I stopped   there\, so I continued on.

  In an EXACTFL node\, all such characters are now folded at compile time   (just as before this commit)\, while the other characters whose folds are   locale-dependent are left unfolded. This means that they have to be   folded at execution time based on the locale in effect at the moment.   Again\, this isn't a change from before. The difference is that now some   of the folds that need to be done at execution time (in regexec) are   potentially multi-char. Some of the code in regexec was trivial to   extend to account for this because of existing infrastructure\, but the   part dealing with regex quantifiers\, had to have more work.

  Also the code that joins EXACTish nodes together had to be expanded to   account for the possibility of multi-character folds within locale   handling. This was fairly easy\, because it already has infrastructure   to handle these under somewhat different circumstances.

  3) In bracketed character classes\, represented by ANYOF nodes\, a new   inversion list was created giving the characters that should be matched   by this node when the runtime locale is UTF-8. The list is ignored   except under that circumstance. To do this\, I created a new ANYOF type   which has an extra SV for the inversion list.

  The edge case that caused the most difficulty is folding involving the   MICRO SIGN\, U+00B5. It folds to the GREEK SMALL LETTER MU\, as does the   GREEK CAPITAL LETTER MU. The MICRO SIGN is the only 0-255 range   character that folds to outside that range. The issue is that it   doesn't naturally fall out that it will match the CAP MU. If we let the   CAP MU fold to the samll mu at compile time (which it can because both   are above-Latin1 and so the fold is the same no matter what locale is in   effect)\, it could appear that the regnode can be downgraded away from   EXACTFL to EXACTFU\, but doing so would cause the MICRO SIGN to not case   insensitvely match the CAP MU. This could be special cased in regcomp   and regexec\, but I wanted to avoid that. Instead the mktables tables   are set up to include the CAP MU as a character whose presence forbids   the downgrading\, so the special casing is in mktables\, and not in the C   code. (END) C​:\perl519\src\t> ---------------------------------------------------------------------

I tried stepping locale.t but fresh_perl_is() blocked my debugging efforts a bit.

--------------------------------------------------------------------- my ($base\, $different\, $comma\, $difference); for ("C"\, @​locales) { # prefer C for the base if available   BEGIN {   if($Config{d_setlocale}) {   require locale; import locale;   }   }   setlocale(LC_NUMERIC\, $_) or next;   my $in = 4.2; # avoid any constant folding bugs   if ((my $s = sprintf("%g"\, $in)) eq "4.2") {   $base ||= $_;   } else {   $different ||= $_;   $difference ||= $s;   $comma ||= $_ if localeconv()->{decimal_point} eq '\,';   }

  last if $base && $different && $comma; }

--------------------------------------------------------------------- sprintf did use "\," instead of "." occasionally.

here is the 1st fresh_perl_is\, ------------------------------------------------------------------------ 1..16 not ok 1 - no locales where LC_NUMERIC breaks # Failed test 1 - no locales where LC_NUMERIC breaks at ./test.pl line 954 # got undef # expected "" # PROG​: # for (qw(Afrikaans Albanian American Basque Bulgarian C Croatian Czech Danish Dutch English Estonian Finnish Galician German Greek Hungarian Indonesian Italian Latvian Lithuanian Norwegian Polish Russian Serbian Slovak Slovenian Swedish Turkish Welsh af da en fi fy ga hu it la mo no no\@​nynorsk ro ru sl)) { # use POSIX qw(locale_h); # use locale; # setlocale(LC_NUMERIC\, "$_") or next; # my $s = sprintf "%g %g"\, 3.1\, 3.1; # next if $s eq '3.1 3.1' || $s =~ /^(3.+1) \1$/; # print "$_ $s\n"; # } # STATUS​: -1 ------------------------------------------------------------------------

I saved the tmp file and ran it manually\, ------------------------------------------------------------------------ C​:\perl519\src\t>..\perl -I..\lib test1.pl

C​:\perl519\src\t> ------------------------------------------------------------------------

next I tried a different test\, ------------------------------------------------------------------------ not ok 15 - POSIX​::strtod() uses underlying locale # Failed test 15 - POSIX​::strtod() uses underlying locale at ./test.pl line 954 # got undef # expected "1.5" # PROG​: # use POSIX; # POSIX​::setlocale(POSIX​::LC_NUMERIC()\,"Albanian"); # my $one_point_5 = POSIX​::strtod("1\,5"); # $one_point_5 =~ s/0+$//; # Remove any trailing zeros # print $one_point_5\, " # "; ------------------------------------------------------------------------- C​:\perl519\src\t>..\perl -I..\lib test1.pl   1.5

  C​:\perl519\src\t>

-------------------------------------------------------------------------

stepping t/test.pl in runperl()\, $runperl is "C​:\perl519\src\perl.exe "-I../lib" "tmp7516A" 2>&1"\, no outer quotes\, result of backticks is undef or empty string according to my watch window. Cwd of perl process is "C​:\perl519\src\t\" when it does backticks. $? after backticks is -1.

Perl Info ``` Flags: category=core severity=medium Site configuration information for perl 5.19.7: Configured by Owner at Thu Nov 28 02:32:44 2013. Summary of my perl5 (revision 5 version 19 subversion 7) configuration: Derived from: 8f47723e28b75530b743941cdd8b07f849ec48e2 Ancestor: 1061065f7a09399eefb50e9a035502621722bcc0 Platform: osname=MSWin32, osvers=5.1, archname=MSWin32-x86-multi-thread uname='' config_args='undef' hint=recommended, useposix=true, d_sigaction=undef useithreads=define, usemultiplicity=define useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef use64bitint=undef, use64bitall=undef, uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cl', ccflags ='-nologo -GF -W3 -O1 -MD -Zi -DNDEBUG -G7 -GL -DWIN32 -D_CONSOLE -DNO_STRICT -DPERL_TEXTMODE_SCRIPTS -DPERL_HASH_FUNC_ONE_AT_A_TIME -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO -D_USE_32BIT_TIME_T', optimize='-O1 -MD -Zi -DNDEBUG -G7 -GL', cppflags='-DWIN32' ccversion='13.10.6030', gccversion='', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=undef, longlongsize=8, d_longdbl=define, longdblsize=8 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='__int64', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='link', ldflags ='-nologo -nodefaultlib -debug -opt:ref,icf -ltcg -libpath:"c:\perl519\lib\CORE" -machine:x86' libpth="C:\Program Files\Microsoft Visual Studio .NET 2003\VC7\lib" libs=oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib netapi32.lib uuid.lib ws2_32.lib mpr.lib winmm.lib version.lib odbc32.lib odbccp32.lib comctl32.lib msvcrt.lib perllibs=oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib netapi32.lib uuid.lib ws2_32.lib mpr.lib winmm.lib version.lib odbc32.lib odbccp32.lib comctl32.lib msvcrt.lib libc=msvcrt.lib, so=dll, useshrplib=true, libperl=perl519.lib gnulibc_version='' Dynamic Linking: dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' ' cccdlflags=' ', lddlflags='-dll -nologo -nodefaultlib -debug -opt:ref,icf -ltcg -libpath:"c:\perl519\lib\CORE" -machine:x86' Locally applied patches: uncommitted-changes 8f47723e28b75530b743941cdd8b07f849ec48e2 @INC for perl 5.19.7: C:/perl519/site/lib C:/perl519/lib . Environment for perl 5.19.7: HOME (unset) LANG (unset) LANGUAGE (unset) LD_LIBRARY_PATH (unset) LOGDIR (unset) PATH=C:\perl519\bin;C:\Program Files\Microsoft Visual Studio .NET 2003\Common7\IDE;C:\Program Files\Microsoft Visual Studio .NET 2003\VC7\BIN;C:\Program Files\Microsoft Visual Studio .NET 2003\Common7\Tools;C:\Program Files\Microsoft Visual Studio .NET 2003\Common7\Tools\bin\prerelease;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32\wbem; PERL_BADLANG (unset) SHELL (unset) ```
p5pRT commented 10 years ago

From @tonycoz

On Tue Jan 28 13​:25​:41 2014\, bulk88 wrote​:

Some time in the last couple days this test on blead started failing on me. WinXP\, 32 bit\, VC 2003.

------------------------------------------------------------------ Test Summary Report ------------------- run/locale.t (Wstat​: 0 Tests​: 16 Failed​: 16) Failed tests​: 1-16 Files=2402\, Tests=694552\, 2421 wallclock secs (77.34 usr + 4.25 sys = 81.59 CPU ) Result​: FAIL NMAKE : fatal error U1077​: '..\perl.exe' : return code '0x10' Stop.

The problem is find_locales() clears PATH\, so qualified_path() can't find cmd.exe.

Tony

p5pRT commented 10 years ago

The RT System itself - Status changed from 'new' to 'open'

p5pRT commented 10 years ago

From @bulk88

On Tue Jan 28 21​:35​:52 2014\, tonyc wrote​:

On Tue Jan 28 13​:25​:41 2014\, bulk88 wrote​:

Some time in the last couple days this test on blead started failing on me. WinXP\, 32 bit\, VC 2003.

------------------------------------------------------------------ Test Summary Report ------------------- run/locale.t (Wstat​: 0 Tests​: 16 Failed​: 16) Failed tests​: 1-16 Files=2402\, Tests=694552\, 2421 wallclock secs (77.34 usr + 4.25 sys

81.59 CPU ) Result​: FAIL NMAKE : fatal error U1077​: '..\perl.exe' : return code '0x10' Stop.

The problem is find_locales() clears PATH\, so qualified_path() can't find cmd.exe.

Tony

Some related commits.

http​://perl5.git.perl.org/perl.git/blobdiff/0eb1d8a4ffdcb76578ec5c9d0c24fa8c80eb3222..645e49edd155d974f77fa182639cf116f11265e7​:/t/pragma/locale.t

http​://perl5.git.perl.org/perl.git/commitdiff/dd8482fcac1d87406d052ae3262cc452d6d23e15

-- bulk88 ~ bulk88 at hotmail.com

p5pRT commented 10 years ago

From @bulk88

On Tue Jan 28 13​:25​:41 2014\, bulk88 wrote​:

This is still a problem but somethings got better from my initial report.


Test Summary Report


run/locale.t (Wstat​: 0 Tests​: 16 Failed​: 4)   Failed tests​: 4-5\, 7\, 10 Files=2409\, Tests=694706\, 3677 wallclock secs (91.17 usr + 26.03 sys = 117.20 CP U) Result​: FAIL NMAKE : fatal error U1077​: '..\perl.exe' : return code '0x4' Stop.


C​:\p519\srcnew\t>perl -I..\lib run/locale.t 1..16 ok 1 - no locales where LC_NUMERIC breaks ok 2 - LC_NUMERIC without environment nor setlocale() has no effect in any local e # using the 'Albanian' locale for LC_NUMERIC tests ok 3 - format() does not look at LC_NUMERIC without 'use locale' not ok 4 - format() looks at LC_NUMERIC with 'use locale' # Failed test 4 - format() looks at LC_NUMERIC with 'use locale' at ./test.pl li ne 954 # got "4.2" # expected "4\,2" # PROG​: # use locale; # format STDOUT = # @​.# # 4.179 # . # write; # STATUS​: 0 not ok 5 - format() looks at LC_NUMERIC with 'use locale "​:not_characters"' # Failed test 5 - format() looks at LC_NUMERIC with 'use locale "​:not_characters "' at ./test.pl line 954 # got "4.2" # expected "4\,2" # PROG​: # use locale "​:not_characters"; # format STDOUT = # @​.# # 4.179 # . # write; # STATUS​: 0 ok 6 - too late to look at the locale at write() time not ok 7 - too late to ignore the locale at write() time # Failed test 7 - too late to ignore the locale at write() time at ./test.pl lin e 954 # got "4.2" # expected "4\,2" # PROG​: # use locale; # format STDOUT = # @​.# # 4.179 # . # { no locale; write; } # STATUS​: 0 ok 8 - version does not clobber version ok 9 - version does not clobber version (via eval) not ok 10 - sprintf() and printf() look at LC_NUMERIC regardless of constant fol ding # Failed test 10 - sprintf() and printf() look at LC_NUMERIC regardless of const ant folding at ./test.pl line 954 # got "4.2 4.2 4.2 4.2 " # expected "4\,2 4\,2 4\,2 4\,2 " # PROG​: # use locale; # use POSIX qw(locale_h); # setlocale(LC_NUMERIC\, ""); # my $in = 4.2; # printf("%g %g %s %s "\, $in\, 4.2\, sprintf("%g"\, $in)\, sprintf("%g"\, 4 .2)); # STATUS​: 0 ok 11 - No compile error on v-strings when setting the locale to non-dot radix a t compile time when default environment has non-dot radix ok 12 - Radix print properly in locale scope\, and without ok 13 - Can do math when radix is a comma ok 14 - POSIX​::strtod() uses underlying locale ok 15 - /il matching of [bracketed] doesn't skip POSIX class if fails individ ch ar ok 16 - /l matching of [bracketed] doesn't skip non-first POSIX class

C​:\p519\srcnew\t>


VC 2008\, Seerver 2003 x64\, 32 bit perl.

-- bulk88 ~ bulk88 at hotmail.com

p5pRT commented 10 years ago

From @bulk88

On Sun Feb 09 19​:38​:54 2014\, bulk88 wrote​:

On Tue Jan 28 13​:25​:41 2014\, bulk88 wrote​:

This is still a problem but somethings got better from my initial report.

Blead verion used is SHA-1​: 388e7c71a000e894d45537b02795a849ec63d162

* [MERGE] fix and refactor re_intuit_start()

-- bulk88 ~ bulk88 at hotmail.com

p5pRT commented 10 years ago

From @bulk88

On Sun Feb 09 19​:39​:47 2014\, bulk88 wrote​:

Seems this ticket got a commit that *partially* fixed it a while ago but nobody posted its existence to the ticket.


Revision​: 8b76dc1d20b9a57382173ce08c4ad10cf5acb5ef Author​: Karl Williamson \public@​khwilliamson\.com Date​: 1/29/2014 11​:51​:38 AM Message​: t/loc_tools.pl​: find_locales() Don't destroy callers ENV

This code was recently moved from lib/locale.t to a new file essentially unchanged\, so that it could be common code. It deletes several environment variables\, such as PATH\, to avoid interference with going out and looking at the locales. In lib/locale.t\, those environment variables are not needed again\, but that isn't true of all the callers. The solution is simply to localize the removal.

This should fix [perl #121106]\, but there remain test failures there.


-- bulk88 ~ bulk88 at hotmail.com

p5pRT commented 10 years ago

From @khwilliamson

On 02/09/2014 08​:56 PM\, bulk88 via RT wrote​:

On Sun Feb 09 19​:39​:47 2014\, bulk88 wrote​:

Seems this ticket got a commit that *partially* fixed it a while ago but nobody posted its existence to the ticket.

--------------------------------------------------------- Revision​: 8b76dc1d20b9a57382173ce08c4ad10cf5acb5ef Author​: Karl Williamson \public@​khwilliamson\.com Date​: 1/29/2014 11​:51​:38 AM Message​: t/loc_tools.pl​: find_locales() Don't destroy callers ENV

This code was recently moved from lib/locale.t to a new file essentially unchanged\, so that it could be common code. It deletes several environment variables\, such as PATH\, to avoid interference with going out and looking at the locales. In lib/locale.t\, those environment variables are not needed again\, but that isn't true of all the callers. The solution is simply to localize the removal.

This should fix [perl #121106]\, but there remain test failures there. ---------------------------------------------------------

I suppose I should have cc'd the ticket\, but since it didn't really fix it\, I didn't. The remaining problems are due\, I think\, to the fact that Windows does not follow the POSIX standard for passing the locale environment to a program. No one has responded to my email concerning this http​://markmail.org/message/y2p6ojfpzlxfukjz

In the absence of a response\, I started thinking it best to document the Windows divergence and to skip the failing tests in this file on Windows\, as had been done all along until the recent commits that enabled them.

p5pRT commented 10 years ago

From @bulk88

On Sun Feb 09 20​:06​:46 2014\, public@​khwilliamson.com wrote​:

I suppose I should have cc'd the ticket\, but since it didn't really fix it\, I didn't. The remaining problems are due\, I think\, to the fact that Windows does not follow the POSIX standard for passing the locale environment to a program. No one has responded to my email concerning this http​://markmail.org/message/y2p6ojfpzlxfukjz

In the absence of a response\, I started thinking it best to document the Windows divergence and to skip the failing tests in this file on Windows\, as had been done all along until the recent commits that enabled them.

Based on IRC discussion\, the question to fixing the remaining failures in this ticket is does the MS C lib ever use env vars ("set" command at cmd prompt) for determining the which locale to use?

After greping the VC 2008 MS C lib source code\, I couldn't find anywhere where it would read an env var in relation to locale (it does read "TZ" though). The locale info is kept in a C static in the C lib\, that is C static intialized from a pointer to a C static locale struct that alot of the following constant in it "#define _CLOCALECP CP_ACP /* "C" locale Code page */". This matches http​://msdn.microsoft.com/en-us/library/x99tb11d.aspx


At program startup\, the equivalent of the following statement is executed​:

setlocale( LC_ALL\, "C" );


TLDR​: system default code page is copied once on startup from a RO page shared between all processes but a process\, if it is crazy\, can change it using undocumented function call. The RO page is read once on kernel boot from the Registry. Meaning of this\, system default is system default. It is not inherited like handles or env vars from a parent process. It is also RO unless you do evil things from kernel drivers. Therefore\, there is no reason for the C lib to read a env var\, since that is just too un-Win32-ese compared with the Win32 concept that default code page is not inherited from a parent process but from the kernel. Of course this can be synthesized\, if you are SFU or Cygwin. If I start a Win32 command prompt shell from a cygwin shell\, then do a "set" in the Win32 shell to dump the Win32 env vars I get "LANG=en_US.UTF-8". If I run this in a plain Win32 shell\, not started from Cygwin shell\, there is no LANG var. So this LANG var has zero meaning except to cygwin's C lib (which isn't MS C lib). Perl on Win32 could synthesize this of course\, but the locale env vars are extremely unlikely to be set except by a parent perl process for testing purposes.

Technical details now\, now\, what is system default code page on Windows? I belive that is whatever GetACP() http​://msdn.microsoft.com/en-us/library/windows/desktop/dd318070%28v=vs.85%29.aspx returns. There is also a GetOEMCP()\, IDK the difference and I'll pretend the OEM doesn't exist for the remainder of the explanation. My knowledge of Win32 and POSIX locale related stuff is terrible. I'll treat it as a opaque number without meaning. It can be the number of MB of physical RAM in the computer as far I know. First\, some background\, since "Windows" is an emulation layer on Windows NT (there is also a nearly abandoned MS POSIX layer equal in design to the Windows layer too)\, kernel32.dll which is the public non-GUI non-POSIX DOS-inspired API of the Windows OS\, a wrapper ontop of the NT API\, which lives in half in user mode code in ntdll.dll and the other half is kernel mode code. NT API from user mode is officially undocumented by API\, but it is an open secret\, most of is documented in the public kernel mode API docs\, or documented by lawsuit settlements against MS\, or documented by WINE\, ReactOS and MS published but unofficial dead trees. Perl when it had NT4 support used a NT API func or 2 from ActiveState's work.

So GetACP fetches a C static in kernel32.dll. The C static I dont think will ever change during the process. There is an undocumented kernel32.dll export called SetCPGlobal where you can set that C static. The kernel32 C static is initialized on process start from the PEB struct\, which is a secret large user mode struct that represents a NT process from Peb->AnsiCodePageData member. AnsiCodePageData is a pointer to a NLS_FILE_HEADER struct. AnsiCodePageData is a user mode pointer set from kernel mode when the process is being initialized kernel size. The NLS_FILE_HEADER * is a RO to the process page mapped from kernel space to all processes. NLS_FILE_HEADER struct has a U16 "CodePage" member where we get our CP number. The kernel also uses the page where the NLS_FILE_HEADER lives for its own idea of system codepage.

This is where my understanding gets hazy. The page is filled out when the kernel initializes\, based on a malloced and later freed NLS_FILE_HEADER * from the NT bootloader. NT bootloader gets the NLS_FILE_HEADER struct by reading an on disk .nls file\, allocs a page for it\, reads it from disk into the page\, and puts the page * in LOADER_PARAMETER_BLOCK. LOADER_PARAMETER_BLOCK * is later passed to kernel when bootloader calls into the kernel. To make things short\, the NT Bootloader gets the data from HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\CodePage\ACP in the registry while still in text mode during the booting process.

-- bulk88 ~ bulk88 at hotmail.com

p5pRT commented 10 years ago

From @steve-m-hay

On 10 February 2014 04​:06\, Karl Williamson \public@​khwilliamson\.com wrote​:

On 02/09/2014 08​:56 PM\, bulk88 via RT wrote​:

On Sun Feb 09 19​:39​:47 2014\, bulk88 wrote​:

Seems this ticket got a commit that *partially* fixed it a while ago but nobody posted its existence to the ticket.

--------------------------------------------------------- Revision​: 8b76dc1d20b9a57382173ce08c4ad10cf5acb5ef Author​: Karl Williamson \public@​khwilliamson\.com Date​: 1/29/2014 11​:51​:38 AM Message​: t/loc_tools.pl​: find_locales() Don't destroy callers ENV

This code was recently moved from lib/locale.t to a new file essentially unchanged\, so that it could be common code. It deletes several environment variables\, such as PATH\, to avoid interference with going out and looking at the locales. In lib/locale.t\, those environment variables are not needed again\, but that isn't true of all the callers. The solution is simply to localize the removal.

This should fix [perl #121106]\, but there remain test failures there. ---------------------------------------------------------

I suppose I should have cc'd the ticket\, but since it didn't really fix it\, I didn't. The remaining problems are due\, I think\, to the fact that Windows does not follow the POSIX standard for passing the locale environment to a program. No one has responded to my email concerning this http​://markmail.org/message/y2p6ojfpzlxfukjz

In the absence of a response\, I started thinking it best to document the Windows divergence and to skip the failing tests in this file on Windows\, as had been done all along until the recent commits that enabled them.

Sorry\, I meant to respond to that email\, but didn't get round to it soon enough.

From previous experience I think it would be best to document the difference on Windows and skip the failing tests. I've run into this before and found that setlocale() works\, but use locale; doesn't. Instead\, settings are picked up from Control Panel's Region and Language options unless overridden by setlocale().

What I wrote in this email is still true​:

http​://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2003-10/msg00244.html

p5pRT commented 10 years ago

From @tonycoz

On Sun Feb 09 20​:06​:46 2014\, public@​khwilliamson.com wrote​:

I suppose I should have cc'd the ticket\, but since it didn't really fix it\, I didn't. The remaining problems are due\, I think\, to the fact that Windows does not follow the POSIX standard for passing the locale environment to a program. No one has responded to my email concerning this http​://markmail.org/message/y2p6ojfpzlxfukjz

In the absence of a response\, I started thinking it best to document the Windows divergence and to skip the failing tests in this file on Windows\, as had been done all along until the recent commits that enabled them.

With your most recent smoke-me​:

J​:\dev\perl\git\perl\t>.\perl run\locale.t 1..16 ok 1 - no locales where LC_NUMERIC breaks ok 2 - LC_NUMERIC without environment nor setlocale() has no effect in any local e # using the 'Albanian' locale for LC_NUMERIC tests ok 3 - format() does not look at LC_NUMERIC without 'use locale' ok 4 - format() looks at LC_NUMERIC with 'use locale' ok 5 - format() looks at LC_NUMERIC with 'use locale "​:not_characters"' ok 6 - too late to look at the locale at write() time ok 7 - too late to ignore the locale at write() time ok 8 - version does not clobber version ok 9 - version does not clobber version (via eval) not ok 10 - sprintf() and printf() look at LC_NUMERIC regardless of constant fol ding # Failed test 10 - sprintf() and printf() look at LC_NUMERIC regardless of const ant folding at ./test.pl line 954 # got "4.2 4.2 4.2 4.2 " # expected "4\,2 4\,2 4\,2 4\,2 " # PROG​: # use locale; # use POSIX qw(locale_h); # setlocale(LC_NUMERIC\, ""); # my $in = 4.2; # printf("%g %g %s %s "\, $in\, 4.2\, sprintf("%g"\, $in)\, sprintf("%g"\, 4 .2)); # STATUS​: 0 ok 11 - No compile error on v-strings when setting the locale to non-dot radix a t compile time when default environment has non-dot radix ok 12 - Radix print properly in locale scope\, and without ok 13 - Can do math when radix is a comma ok 14 - POSIX​::strtod() uses underlying locale ok 15 - /il matching of [bracketed] doesn't skip POSIX class if fails individ ch ar ok 16 - /l matching of [bracketed] doesn't skip non-first POSIX class

commit fc2f550db699a9deba5be34dddfed0e129f0bc4c Author​: Karl Williamson \public@​khwilliamson\.com Date​: Mon Feb 10 13​:05​:08 2014 -0700

  locale.c​: Use POSIX rules on Windows

  For smoking

Tony

p5pRT commented 10 years ago

From @khwilliamson

On 02/10/2014 01​:31 AM\, Steve Hay wrote​:

On 10 February 2014 04​:06\, Karl Williamson \public@​khwilliamson\.com wrote​:

On 02/09/2014 08​:56 PM\, bulk88 via RT wrote​:

On Sun Feb 09 19​:39​:47 2014\, bulk88 wrote​:

Seems this ticket got a commit that *partially* fixed it a while ago but nobody posted its existence to the ticket.

--------------------------------------------------------- Revision​: 8b76dc1d20b9a57382173ce08c4ad10cf5acb5ef Author​: Karl Williamson \public@​khwilliamson\.com Date​: 1/29/2014 11​:51​:38 AM Message​: t/loc_tools.pl​: find_locales() Don't destroy callers ENV

This code was recently moved from lib/locale.t to a new file essentially unchanged\, so that it could be common code. It deletes several environment variables\, such as PATH\, to avoid interference with going out and looking at the locales. In lib/locale.t\, those environment variables are not needed again\, but that isn't true of all the callers. The solution is simply to localize the removal.

This should fix [perl #121106]\, but there remain test failures there. ---------------------------------------------------------

I suppose I should have cc'd the ticket\, but since it didn't really fix it\, I didn't. The remaining problems are due\, I think\, to the fact that Windows does not follow the POSIX standard for passing the locale environment to a program. No one has responded to my email concerning this http​://markmail.org/message/y2p6ojfpzlxfukjz

In the absence of a response\, I started thinking it best to document the Windows divergence and to skip the failing tests in this file on Windows\, as had been done all along until the recent commits that enabled them.

Sorry\, I meant to respond to that email\, but didn't get round to it soon enough.

From previous experience I think it would be best to document the difference on Windows and skip the failing tests. I've run into this before and found that setlocale() works\, but use locale; doesn't. Instead\, settings are picked up from Control Panel's Region and Language options unless overridden by setlocale().

Let me clarify the difference between setlocale and 'use locale'. perllocale has been cleaned up a lot\, and the code in 5.19 much more closely follows what it documents.

setlocale is a runtime function that changes the underlying locale the program is running in. That underlying locale is not visible to the Perl program outside the lexical scope of the compile-time 'use locale' pragma\, with some notable exceptions\, now documented in perllocale -- essentially things that are outside perl\, such as explicit calls to libc functions\, including through the POSIX​:: module.

What I wrote in this email is still true​:

http​://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2003-10/msg00244.html

So above\, you said we should just document the differences\, but in the message\, you say you would prefer having the environment variables take effect in Perl. We can go either way. I have written a patch that Tony tested on Windows and posted the results on this ticket. One test fails\, but its failure is unrelated to this issue.

bulk88 doesn't have an opinion on this. By applying the patch\, programs would run more similarly on Windows and non-Windows machines in this regard; it would be a change in behavior.

p5pRT commented 10 years ago

From @steve-m-hay

On 10 Feb 2014 23​:53\, "Karl Williamson" \public@​khwilliamson\.com wrote​:

On 02/10/2014 01​:31 AM\, Steve Hay wrote​:

On 10 February 2014 04​:06\, Karl Williamson \public@​khwilliamson\.com wrote​:

On 02/09/2014 08​:56 PM\, bulk88 via RT wrote​:

On Sun Feb 09 19​:39​:47 2014\, bulk88 wrote​:

Seems this ticket got a commit that *partially* fixed it a while ago but nobody posted its existence to the ticket.

--------------------------------------------------------- Revision​: 8b76dc1d20b9a57382173ce08c4ad10cf5acb5ef Author​: Karl Williamson \public@​khwilliamson\.com Date​: 1/29/2014 11​:51​:38 AM Message​: t/loc_tools.pl​: find_locales() Don't destroy callers ENV

This code was recently moved from lib/locale.t to a new file essentially unchanged\, so that it could be common code. It deletes several environment variables\, such as PATH\, to avoid interference with going out and looking at the locales. In lib/locale.t\, those environment variables are not needed again\, but that isn't true of all the callers. The solution is simply to localize the removal.

This should fix [perl #121106]\, but there remain test failures there. ---------------------------------------------------------

I suppose I should have cc'd the ticket\, but since it didn't really fix it\, I didn't. The remaining problems are due\, I think\, to the fact that Windows does not follow the POSIX standard for passing the locale environment to a program. No one has responded to my email concerning this http​://markmail.org/message/y2p6ojfpzlxfukjz

In the absence of a response\, I started thinking it best to document the Windows divergence and to skip the failing tests in this file on Windows\, as had been done all along until the recent commits that enabled them.

Sorry\, I meant to respond to that email\, but didn't get round to it soon enough.

From previous experience I think it would be best to document the

difference on Windows and skip the failing tests. I've run into this before and found that setlocale() works\, but use locale; doesn't. Instead\, settings are picked up from Control Panel's Region and Language options unless overridden by setlocale().

Let me clarify the difference between setlocale and 'use locale'. perllocale has been cleaned up a lot\, and the code in 5.19 much more closely follows what it documents.

setlocale is a runtime function that changes the underlying locale the program is running in. That underlying locale is not visible to the Perl program outside the lexical scope of the compile-time 'use locale' pragma\, with some notable exceptions\, now documented in perllocale -- essentially things that are outside perl\, such as explicit calls to libc functions\, including through the POSIX​:: module.

What I wrote in this email is still true​:

http​://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2003-10/msg00244.html

So above\, you said we should just document the differences\, but in the message\, you say you would prefer having the environment variables take effect in Perl. We can go either way. I have written a patch that Tony tested on Windows and posted the results on this ticket. One test fails\, but its failure is unrelated to this issue.

bulk88 doesn't have an opinion on this. By applying the patch\, programs would run more similarly on Windows and non-Windows machines in this regard; it would be a change in behavior.

Without yet having looked at the patch\, I would say it would be nice to have environment variable control\, and if the absence of any such variables returns things to the current Control Panel controlled state then there should be no objections to a change in behaviour.

If that's what the patch achieves then I'm in favour; if not\, then would that be possible?

Apologies for only half looking at this so far. I will try to have a proper look in the next day or two.

p5pRT commented 10 years ago

From @steve-m-hay

On 11 February 2014 00​:27\, Steve Hay \steve\.m\.hay@​googlemail\.com wrote​:

On 10 Feb 2014 23​:53\, "Karl Williamson" \public@​khwilliamson\.com wrote​:

On 02/10/2014 01​:31 AM\, Steve Hay wrote​:

On 10 February 2014 04​:06\, Karl Williamson \public@​khwilliamson\.com wrote​:

On 02/09/2014 08​:56 PM\, bulk88 via RT wrote​:

On Sun Feb 09 19​:39​:47 2014\, bulk88 wrote​:

Seems this ticket got a commit that *partially* fixed it a while ago but nobody posted its existence to the ticket.

--------------------------------------------------------- Revision​: 8b76dc1d20b9a57382173ce08c4ad10cf5acb5ef Author​: Karl Williamson \public@​khwilliamson\.com Date​: 1/29/2014 11​:51​:38 AM Message​: t/loc_tools.pl​: find_locales() Don't destroy callers ENV

This code was recently moved from lib/locale.t to a new file essentially unchanged\, so that it could be common code. It deletes several environment variables\, such as PATH\, to avoid interference with going out and looking at the locales. In lib/locale.t\, those environment variables are not needed again\, but that isn't true of all the callers. The solution is simply to localize the removal.

This should fix [perl #121106]\, but there remain test failures there. ---------------------------------------------------------

I suppose I should have cc'd the ticket\, but since it didn't really fix it\, I didn't. The remaining problems are due\, I think\, to the fact that Windows does not follow the POSIX standard for passing the locale environment to a program. No one has responded to my email concerning this http​://markmail.org/message/y2p6ojfpzlxfukjz

In the absence of a response\, I started thinking it best to document the Windows divergence and to skip the failing tests in this file on Windows\, as had been done all along until the recent commits that enabled them.

Sorry\, I meant to respond to that email\, but didn't get round to it soon enough.

From previous experience I think it would be best to document the

difference on Windows and skip the failing tests. I've run into this before and found that setlocale() works\, but use locale; doesn't. Instead\, settings are picked up from Control Panel's Region and Language options unless overridden by setlocale().

Let me clarify the difference between setlocale and 'use locale'. perllocale has been cleaned up a lot\, and the code in 5.19 much more closely follows what it documents.

setlocale is a runtime function that changes the underlying locale the program is running in. That underlying locale is not visible to the Perl program outside the lexical scope of the compile-time 'use locale' pragma\, with some notable exceptions\, now documented in perllocale -- essentially things that are outside perl\, such as explicit calls to libc functions\, including through the POSIX​:: module.

What I wrote in this email is still true​:

http​://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2003-10/msg00244.html

So above\, you said we should just document the differences\, but in the message\, you say you would prefer having the environment variables take effect in Perl. We can go either way. I have written a patch that Tony tested on Windows and posted the results on this ticket. One test fails\, but its failure is unrelated to this issue.

bulk88 doesn't have an opinion on this. By applying the patch\, programs would run more similarly on Windows and non-Windows machines in this regard; it would be a change in behavior.

Without yet having looked at the patch\, I would say it would be nice to have environment variable control\, and if the absence of any such variables returns things to the current Control Panel controlled state then there should be no objections to a change in behaviour.

If that's what the patch achieves then I'm in favour; if not\, then would that be possible?

Apologies for only half looking at this so far. I will try to have a proper look in the next day or two.

I've just checked out smoke-me/khw-locale to have a play\, but it doesn't build for me (VC++ 2010)​:

  cl -c -nologo -GF -W3 -I..\lib\CORE -I.\include -I. -I.. -DWIN32 -D_CONSOLE -DNO_STRICT -D_CRT_SECURE_NO_DEPRECATE -D_CRT_NONSTDC_NO_DEPRECATE -DPERLDLL -DPERL_CORE -O1 -MD -Zi -DNDEBUG -GL -DPERL_EXTERNAL_GLOB -DPERL_IS_MINIPERL -Fo.\mini\locale.obj ..\locale.c locale.c ..\locale.c(485) : warning C4013​: 'my_setlocale' undefined; assuming extern returning int ..\locale.c(492) : warning C4047​: '=' : 'char *' differs in levels of indirection from 'int' ..\locale.c(499) : warning C4047​: '=' : 'char *' differs in levels of indirection from 'int' ..\locale.c(506) : warning C4047​: '=' : 'char *' differs in levels of indirection from 'int' [...]   link -subsystem​:console -out​:..\miniperl.exe @​C​:\Users\Steve\AppData\Local\Temp\nm8D04.tmp locale.obj : error LNK2001​: unresolved external symbol _my_setlocale ..\miniperl.exe : fatal error LNK1120​: 1 unresolved externals

p5pRT commented 10 years ago

From @khwilliamson

On 02/11/2014 02​:17 PM\, Steve Hay wrote​:

On 11 February 2014 00​:27\, Steve Hay \steve\.m\.hay@​googlemail\.com wrote​:

On 10 Feb 2014 23​:53\, "Karl Williamson" \public@​khwilliamson\.com wrote​:

On 02/10/2014 01​:31 AM\, Steve Hay wrote​:

On 10 February 2014 04​:06\, Karl Williamson \public@​khwilliamson\.com wrote​:

On 02/09/2014 08​:56 PM\, bulk88 via RT wrote​:

On Sun Feb 09 19​:39​:47 2014\, bulk88 wrote​:

Seems this ticket got a commit that *partially* fixed it a while ago but nobody posted its existence to the ticket.

--------------------------------------------------------- Revision​: 8b76dc1d20b9a57382173ce08c4ad10cf5acb5ef Author​: Karl Williamson \public@​khwilliamson\.com Date​: 1/29/2014 11​:51​:38 AM Message​: t/loc_tools.pl​: find_locales() Don't destroy callers ENV

This code was recently moved from lib/locale.t to a new file essentially unchanged\, so that it could be common code. It deletes several environment variables\, such as PATH\, to avoid interference with going out and looking at the locales. In lib/locale.t\, those environment variables are not needed again\, but that isn't true of all the callers. The solution is simply to localize the removal.

This should fix [perl #121106]\, but there remain test failures there. ---------------------------------------------------------

I suppose I should have cc'd the ticket\, but since it didn't really fix it\, I didn't. The remaining problems are due\, I think\, to the fact that Windows does not follow the POSIX standard for passing the locale environment to a program. No one has responded to my email concerning this http​://markmail.org/message/y2p6ojfpzlxfukjz

In the absence of a response\, I started thinking it best to document the Windows divergence and to skip the failing tests in this file on Windows\, as had been done all along until the recent commits that enabled them.

Sorry\, I meant to respond to that email\, but didn't get round to it soon enough.

From previous experience I think it would be best to document the

difference on Windows and skip the failing tests. I've run into this before and found that setlocale() works\, but use locale; doesn't. Instead\, settings are picked up from Control Panel's Region and Language options unless overridden by setlocale().

Let me clarify the difference between setlocale and 'use locale'. perllocale has been cleaned up a lot\, and the code in 5.19 much more closely follows what it documents.

setlocale is a runtime function that changes the underlying locale the program is running in. That underlying locale is not visible to the Perl program outside the lexical scope of the compile-time 'use locale' pragma\, with some notable exceptions\, now documented in perllocale -- essentially things that are outside perl\, such as explicit calls to libc functions\, including through the POSIX​:: module.

What I wrote in this email is still true​:

http​://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2003-10/msg00244.html

So above\, you said we should just document the differences\, but in the message\, you say you would prefer having the environment variables take effect in Perl. We can go either way. I have written a patch that Tony tested on Windows and posted the results on this ticket. One test fails\, but its failure is unrelated to this issue.

bulk88 doesn't have an opinion on this. By applying the patch\, programs would run more similarly on Windows and non-Windows machines in this regard; it would be a change in behavior.

Without yet having looked at the patch\, I would say it would be nice to have environment variable control\, and if the absence of any such variables returns things to the current Control Panel controlled state then there should be no objections to a change in behaviour.

If that's what the patch achieves then I'm in favour; if not\, then would that be possible?

Apologies for only half looking at this so far. I will try to have a proper look in the next day or two.

I've just checked out smoke-me/khw-locale to have a play\, but it doesn't build for me (VC++ 2010)​:

     cl \-c \-nologo \-GF \-W3 \-I\.\.\\lib\\CORE \-I\.\\include \-I\. \-I\.\.

-DWIN32 -D_CONSOLE -DNO_STRICT -D_CRT_SECURE_NO_DEPRECATE -D_CRT_NONSTDC_NO_DEPRECATE -DPERLDLL -DPERL_CORE -O1 -MD -Zi -DNDEBUG -GL -DPERL_EXTERNAL_GLOB -DPERL_IS_MINIPERL -Fo.\mini\locale.obj ..\locale.c locale.c ..\locale.c(485) : warning C4013​: 'my_setlocale' undefined; assuming extern returning int ..\locale.c(492) : warning C4047​: '=' : 'char *' differs in levels of indirection from 'int' ..\locale.c(499) : warning C4047​: '=' : 'char *' differs in levels of indirection from 'int' ..\locale.c(506) : warning C4047​: '=' : 'char *' differs in levels of indirection from 'int' [...] link -subsystem​:console -out​:..\miniperl.exe @​C​:\Users\Steve\AppData\Local\Temp\nm8D04.tmp locale.obj : error LNK2001​: unresolved external symbol _my_setlocale ..\miniperl.exe : fatal error LNK1120​: 1 unresolved externals

That push was supposed to be a better patch than yesterday\, but for testing on my non-Windows machine\, I reversed the sense of the #ifdefs\, and forgot to unreverse them before pushing.

Anyway\, that branch now has something that I hope works better.

What I've done is change the patch to be just a wrapper around setlocale() which intercepts calls of the form setlocale(foo\, "") and goes looking in the environment\, and uses any found. If none are found\, it calls the regular setlocale() with the inputs unchanged\, so there's no change in behavior unless the environment contains the appropriate variables. This way\, it is transparent everywhere. I #ifdef'd out the patch from yesterday.

p5pRT commented 10 years ago

From @bulk88

On Tue Feb 11 15​:42​:01 2014\, public@​khwilliamson.com wrote​:

That push was supposed to be a better patch than yesterday\, but for testing on my non-Windows machine\, I reversed the sense of the #ifdefs\, and forgot to unreverse them before pushing.

Anyway\, that branch now has something that I hope works better.

What I've done is change the patch to be just a wrapper around setlocale() which intercepts calls of the form setlocale(foo\, "") and goes looking in the environment\, and uses any found. If none are found\, it calls the regular setlocale() with the inputs unchanged\, so there's no change in behavior unless the environment contains the appropriate variables. This way\, it is transparent everywhere. I #ifdef'd out the patch from yesterday.

Towards the end of http​://perl5.git.perl.org/perl.git/blobdiff/4a00dd4ed5820d915f024905d1a028e24f2f7d3b..ceab2a5a64ab6808cf5128e56b99b3edb4c205d3​:/locale.c in "@​@​ -421\,34 +482\,170 @​@​ Perl_init_i18nl10n(pTHX_ int printwarn) " it looks like there is alot of duplicate code.


+ { + char * lc_monetary = PerlEnv_getenv("LC_MONETARY"); + if (! lc_monetary) { + lc_monetary = lang; + } + if (lc_monetary && strNE(lc_monetary\, "")) { + if (! setlocale(LC_MONETARY\, lc_monetary)) { + setlocale_failure = TRUE; + } + } + }


That should be a function that takes pTHX_\, and a struct *. The struct * points to a char * and constant. The struct * are into a const static array of structs\, each struct consisting of a char * and constant. The lines of initializer of the array are #ifdefed based on whether the constant exists. In Perl_init_i18nl10n then a for loop with sizeof() in the array is called for each array slice that represents a constant.

-- bulk88 ~ bulk88 at hotmail.com

p5pRT commented 10 years ago

From @steve-m-hay

On 11 February 2014 23​:41\, Karl Williamson \public@​khwilliamson\.com wrote​:

On 02/11/2014 02​:17 PM\, Steve Hay wrote​:

On 11 February 2014 00​:27\, Steve Hay \steve\.m\.hay@​googlemail\.com wrote​:

On 10 Feb 2014 23​:53\, "Karl Williamson" \public@​khwilliamson\.com wrote​:

On 02/10/2014 01​:31 AM\, Steve Hay wrote​:

On 10 February 2014 04​:06\, Karl Williamson \public@​khwilliamson\.com wrote​:

On 02/09/2014 08​:56 PM\, bulk88 via RT wrote​:

On Sun Feb 09 19​:39​:47 2014\, bulk88 wrote​:

Seems this ticket got a commit that *partially* fixed it a while ago but nobody posted its existence to the ticket.

--------------------------------------------------------- Revision​: 8b76dc1d20b9a57382173ce08c4ad10cf5acb5ef Author​: Karl Williamson \public@​khwilliamson\.com Date​: 1/29/2014 11​:51​:38 AM Message​: t/loc_tools.pl​: find_locales() Don't destroy callers ENV

This code was recently moved from lib/locale.t to a new file essentially unchanged\, so that it could be common code. It deletes several environment variables\, such as PATH\, to avoid interference with going out and looking at the locales. In lib/locale.t\, those environment variables are not needed again\, but that isn't true of all the callers. The solution is simply to localize the removal.

This should fix [perl #121106]\, but there remain test failures there. ---------------------------------------------------------

I suppose I should have cc'd the ticket\, but since it didn't really fix it\, I didn't. The remaining problems are due\, I think\, to the fact that Windows does not follow the POSIX standard for passing the locale environment to a program. No one has responded to my email concerning this http​://markmail.org/message/y2p6ojfpzlxfukjz

In the absence of a response\, I started thinking it best to document the Windows divergence and to skip the failing tests in this file on Windows\, as had been done all along until the recent commits that enabled them.

Sorry\, I meant to respond to that email\, but didn't get round to it soon enough.

From previous experience I think it would be best to document the

difference on Windows and skip the failing tests. I've run into this before and found that setlocale() works\, but use locale; doesn't. Instead\, settings are picked up from Control Panel's Region and Language options unless overridden by setlocale().

Let me clarify the difference between setlocale and 'use locale'. perllocale has been cleaned up a lot\, and the code in 5.19 much more closely follows what it documents.

setlocale is a runtime function that changes the underlying locale the program is running in. That underlying locale is not visible to the Perl program outside the lexical scope of the compile-time 'use locale' pragma\, with some notable exceptions\, now documented in perllocale -- essentially things that are outside perl\, such as explicit calls to libc functions\, including through the POSIX​:: module.

What I wrote in this email is still true​:

http​://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2003-10/msg00244.html

So above\, you said we should just document the differences\, but in the message\, you say you would prefer having the environment variables take effect in Perl. We can go either way. I have written a patch that Tony tested on Windows and posted the results on this ticket. One test fails\, but its failure is unrelated to this issue.

bulk88 doesn't have an opinion on this. By applying the patch\, programs would run more similarly on Windows and non-Windows machines in this regard; it would be a change in behavior.

Without yet having looked at the patch\, I would say it would be nice to have environment variable control\, and if the absence of any such variables returns things to the current Control Panel controlled state then there should be no objections to a change in behaviour.

If that's what the patch achieves then I'm in favour; if not\, then would that be possible?

Apologies for only half looking at this so far. I will try to have a proper look in the next day or two.

I've just checked out smoke-me/khw-locale to have a play\, but it doesn't build for me (VC++ 2010)​:

     cl \-c \-nologo \-GF \-W3 \-I\.\.\\lib\\CORE \-I\.\\include \-I\. \-I\.\.

-DWIN32 -D_CONSOLE -DNO_STRICT -D_CRT_SECURE_NO_DEPRECATE -D_CRT_NONSTDC_NO_DEPRECATE -DPERLDLL -DPERL_CORE -O1 -MD -Zi -DNDEBUG -GL -DPERL_EXTERNAL_GLOB -DPERL_IS_MINIPERL -Fo.\mini\locale.obj ..\locale.c locale.c ..\locale.c(485) : warning C4013​: 'my_setlocale' undefined; assuming extern returning int ..\locale.c(492) : warning C4047​: '=' : 'char *' differs in levels of indirection from 'int' ..\locale.c(499) : warning C4047​: '=' : 'char *' differs in levels of indirection from 'int' ..\locale.c(506) : warning C4047​: '=' : 'char *' differs in levels of indirection from 'int' [...] link -subsystem​:console -out​:..\miniperl.exe @​C​:\Users\Steve\AppData\Local\Temp\nm8D04.tmp locale.obj : error LNK2001​: unresolved external symbol _my_setlocale ..\miniperl.exe : fatal error LNK1120​: 1 unresolved externals

That push was supposed to be a better patch than yesterday\, but for testing on my non-Windows machine\, I reversed the sense of the #ifdefs\, and forgot to unreverse them before pushing.

Anyway\, that branch now has something that I hope works better.

What I've done is change the patch to be just a wrapper around setlocale() which intercepts calls of the form setlocale(foo\, "") and goes looking in the environment\, and uses any found. If none are found\, it calls the regular setlocale() with the inputs unchanged\, so there's no change in behavior unless the environment contains the appropriate variables. This way\, it is transparent everywhere. I #ifdef'd out the patch from yesterday.

This looks good to me (including ALL tests passing)\, except for one thing that surprised me​:

With my Control Panel setting set to German and an invalid LC_ALL set in the environment (I set it to "XXX") I get a warning about the locale setting failing (as expected)\, but it then says that it will fall back to the standard locale ("C")\, and the output I get from a POSIX​::strftime() call suggests that's exactly what it's done since the output is English​:

C​:\Dev\Git\perl>perl -MPOSIX -e "print strftime('%#x'\, localtime)" perl​: warning​: Setting locale failed. perl​: warning​: Please check that your locale settings​:   LC_ALL = "XXX"\,   LANG = (unset)   are supported and installed on your system. perl​: warning​: Falling back to the standard locale ("C"). Wednesday\, February 12\, 2014

I was expecting it to fall back to my system default (German\, as specified in Control Panel) in this case\, exactly as like it uses if there is no LC_ALL set in the environment.

Why does it fall back to "C" instead?

p5pRT commented 10 years ago

From @khwilliamson

On 02/12/2014 02​:37 AM\, Steve Hay wrote​:

I was expecting it to fall back to my system default (German\, as specified in Control Panel) in this case\, exactly as like it uses if there is no LC_ALL set in the environment.

Why does it fall back to "C" instead?

Because it's a case I hadn't considered. I'll look into it

p5pRT commented 10 years ago

From @khwilliamson

On 02/12/2014 07​:05 AM\, Karl Williamson wrote​:

On 02/12/2014 02​:37 AM\, Steve Hay wrote​:

I was expecting it to fall back to my system default (German\, as specified in Control Panel) in this case\, exactly as like it uses if there is no LC_ALL set in the environment.

Why does it fall back to "C" instead?

Because it's a case I hadn't considered. I'll look into it

The branch now has a version that will fall back to the system default on Windows. Please try it out\, and let me know. Please also look at the pod changes to see if they are accurate and adequate.

p5pRT commented 10 years ago

From @steve-m-hay

On 12 February 2014 18​:06\, Karl Williamson \public@​khwilliamson\.com wrote​:

On 02/12/2014 07​:05 AM\, Karl Williamson wrote​:

On 02/12/2014 02​:37 AM\, Steve Hay wrote​:

I was expecting it to fall back to my system default (German\, as specified in Control Panel) in this case\, exactly as like it uses if there is no LC_ALL set in the environment.

Why does it fall back to "C" instead?

Because it's a case I hadn't considered. I'll look into it

The branch now has a version that will fall back to the system default on Windows. Please try it out\, and let me know. Please also look at the pod changes to see if they are accurate and adequate.

With Control Panel set to English (United Kingdom) and LC_ALL set to XXX it works (or at the very least claims to work\, there being no difference between "C" and "English" in this case) as expected\, now falling back to the system default​:

C​:\Dev\Git\perl>perl -MPOSIX -e "print strftime('%#x'\, localtime)" perl​: warning​: Setting locale failed. perl​: warning​: Please check that your locale settings​:   LC_ALL = "XXX"\,   LANG = (unset)   are supported and installed on your system. perl​: warning​: Falling back to the system default locale. 13 February 2014

But if I set the Control Panel to German (Germany) (and still have LC_ALL=XXX) then something odd happens​:

C​:\Dev\Git\perl>perl -MPOSIX -e "print strftime('%#x'\, localtime)" perl​: warning​: Setting locale failed. perl​: warning​: Please check that your locale settings​:   LC_ALL = "XXX"\,   LANG = (unset)   are supported and installed on your system. perl​: warning​: Falling back to the system default locale. Invalid version format (non-numeric data) at C​:/Dev/Git/perl/lib/Exporter.pm line 3. Compilation failed in require at C​:/Dev/Git/perl/lib/Fcntl.pm line 61. Compilation failed in require at C​:/Dev/Git/perl/lib/POSIX.pm line 17. BEGIN failed--compilation aborted at C​:/Dev/Git/perl/lib/POSIX.pm line 17. Compilation failed in require. BEGIN failed--compilation aborted.

Randomly trying other languages\, it appears (I didn't go through them all) that all the English* ones work but no others.

The POD changes look fine.

p5pRT commented 10 years ago

From @khwilliamson

On 02/13/2014 01​:47 AM\, Steve Hay wrote​:

On 12 February 2014 18​:06\, Karl Williamson \public@​khwilliamson\.com wrote​:

On 02/12/2014 07​:05 AM\, Karl Williamson wrote​:

On 02/12/2014 02​:37 AM\, Steve Hay wrote​:

I was expecting it to fall back to my system default (German\, as specified in Control Panel) in this case\, exactly as like it uses if there is no LC_ALL set in the environment.

Why does it fall back to "C" instead?

Because it's a case I hadn't considered. I'll look into it

The branch now has a version that will fall back to the system default on Windows. Please try it out\, and let me know. Please also look at the pod changes to see if they are accurate and adequate.

With Control Panel set to English (United Kingdom) and LC_ALL set to XXX it works (or at the very least claims to work\, there being no difference between "C" and "English" in this case) as expected\, now falling back to the system default​:

C​:\Dev\Git\perl>perl -MPOSIX -e "print strftime('%#x'\, localtime)" perl​: warning​: Setting locale failed. perl​: warning​: Please check that your locale settings​: LC_ALL = "XXX"\, LANG = (unset) are supported and installed on your system. perl​: warning​: Falling back to the system default locale. 13 February 2014

But if I set the Control Panel to German (Germany) (and still have LC_ALL=XXX) then something odd happens​:

C​:\Dev\Git\perl>perl -MPOSIX -e "print strftime('%#x'\, localtime)" perl​: warning​: Setting locale failed. perl​: warning​: Please check that your locale settings​: LC_ALL = "XXX"\, LANG = (unset) are supported and installed on your system. perl​: warning​: Falling back to the system default locale. Invalid version format (non-numeric data) at C​:/Dev/Git/perl/lib/Exporter.pm line 3. Compilation failed in require at C​:/Dev/Git/perl/lib/Fcntl.pm line 61. Compilation failed in require at C​:/Dev/Git/perl/lib/POSIX.pm line 17. BEGIN failed--compilation aborted at C​:/Dev/Git/perl/lib/POSIX.pm line 17. Compilation failed in require. BEGIN failed--compilation aborted.

Randomly trying other languages\, it appears (I didn't go through them all) that all the English* ones work but no others.

The POD changes look fine.

Please try it with the new smoke-me version

p5pRT commented 10 years ago

From @steve-m-hay

On 14 February 2014 06​:00\, Karl Williamson \public@​khwilliamson\.com wrote​:

On 02/13/2014 01​:47 AM\, Steve Hay wrote​:

On 12 February 2014 18​:06\, Karl Williamson \public@​khwilliamson\.com wrote​:

On 02/12/2014 07​:05 AM\, Karl Williamson wrote​:

On 02/12/2014 02​:37 AM\, Steve Hay wrote​:

I was expecting it to fall back to my system default (German\, as specified in Control Panel) in this case\, exactly as like it uses if there is no LC_ALL set in the environment.

Why does it fall back to "C" instead?

Because it's a case I hadn't considered. I'll look into it

The branch now has a version that will fall back to the system default on Windows. Please try it out\, and let me know. Please also look at the pod changes to see if they are accurate and adequate.

With Control Panel set to English (United Kingdom) and LC_ALL set to XXX it works (or at the very least claims to work\, there being no difference between "C" and "English" in this case) as expected\, now falling back to the system default​:

C​:\Dev\Git\perl>perl -MPOSIX -e "print strftime('%#x'\, localtime)" perl​: warning​: Setting locale failed. perl​: warning​: Please check that your locale settings​: LC_ALL = "XXX"\, LANG = (unset) are supported and installed on your system. perl​: warning​: Falling back to the system default locale. 13 February 2014

But if I set the Control Panel to German (Germany) (and still have LC_ALL=XXX) then something odd happens​:

C​:\Dev\Git\perl>perl -MPOSIX -e "print strftime('%#x'\, localtime)" perl​: warning​: Setting locale failed. perl​: warning​: Please check that your locale settings​: LC_ALL = "XXX"\, LANG = (unset) are supported and installed on your system. perl​: warning​: Falling back to the system default locale. Invalid version format (non-numeric data) at C​:/Dev/Git/perl/lib/Exporter.pm line 3. Compilation failed in require at C​:/Dev/Git/perl/lib/Fcntl.pm line 61. Compilation failed in require at C​:/Dev/Git/perl/lib/POSIX.pm line 17. BEGIN failed--compilation aborted at C​:/Dev/Git/perl/lib/POSIX.pm line 17. Compilation failed in require. BEGIN failed--compilation aborted.

Randomly trying other languages\, it appears (I didn't go through them all) that all the English* ones work but no others.

The POD changes look fine.

Please try it with the new smoke-me version

Sorry\, this is still the same (testing 3eddf8fb44).

p5pRT commented 10 years ago

From @khwilliamson

On 02/14/2014 01​:34 AM\, Steve Hay wrote​:

On 14 February 2014 06​:00\, Karl Williamson \public@​khwilliamson\.com wrote​:

On 02/13/2014 01​:47 AM\, Steve Hay wrote​:

On 12 February 2014 18​:06\, Karl Williamson \public@​khwilliamson\.com wrote​:

On 02/12/2014 07​:05 AM\, Karl Williamson wrote​:

On 02/12/2014 02​:37 AM\, Steve Hay wrote​:

I was expecting it to fall back to my system default (German\, as specified in Control Panel) in this case\, exactly as like it uses if there is no LC_ALL set in the environment.

Why does it fall back to "C" instead?

Because it's a case I hadn't considered. I'll look into it

The branch now has a version that will fall back to the system default on Windows. Please try it out\, and let me know. Please also look at the pod changes to see if they are accurate and adequate.

With Control Panel set to English (United Kingdom) and LC_ALL set to XXX it works (or at the very least claims to work\, there being no difference between "C" and "English" in this case) as expected\, now falling back to the system default​:

C​:\Dev\Git\perl>perl -MPOSIX -e "print strftime('%#x'\, localtime)" perl​: warning​: Setting locale failed. perl​: warning​: Please check that your locale settings​: LC_ALL = "XXX"\, LANG = (unset) are supported and installed on your system. perl​: warning​: Falling back to the system default locale. 13 February 2014

But if I set the Control Panel to German (Germany) (and still have LC_ALL=XXX) then something odd happens​:

C​:\Dev\Git\perl>perl -MPOSIX -e "print strftime('%#x'\, localtime)" perl​: warning​: Setting locale failed. perl​: warning​: Please check that your locale settings​: LC_ALL = "XXX"\, LANG = (unset) are supported and installed on your system. perl​: warning​: Falling back to the system default locale. Invalid version format (non-numeric data) at C​:/Dev/Git/perl/lib/Exporter.pm line 3. Compilation failed in require at C​:/Dev/Git/perl/lib/Fcntl.pm line 61. Compilation failed in require at C​:/Dev/Git/perl/lib/POSIX.pm line 17. BEGIN failed--compilation aborted at C​:/Dev/Git/perl/lib/POSIX.pm line 17. Compilation failed in require. BEGIN failed--compilation aborted.

Randomly trying other languages\, it appears (I didn't go through them all) that all the English* ones work but no others.

The POD changes look fine.

Please try it with the new smoke-me version

Sorry\, this is still the same (testing 3eddf8fb44).

I abandoned trying to put bandaids on\, and refactored the code some. In doing so\, I changed it so that in general if initialization fails\, it goes to the next lower priority environment variable\, and repeats until success\, or it reaches the C locale. On Windows\, the system default is tried just before C.

p5pRT commented 10 years ago

From @steve-m-hay

On 14 February 2014 23​:28\, Karl Williamson \public@​khwilliamson\.com wrote​:

On 02/14/2014 01​:34 AM\, Steve Hay wrote​:

On 14 February 2014 06​:00\, Karl Williamson \public@​khwilliamson\.com wrote​:

On 02/13/2014 01​:47 AM\, Steve Hay wrote​:

On 12 February 2014 18​:06\, Karl Williamson \public@​khwilliamson\.com wrote​:

On 02/12/2014 07​:05 AM\, Karl Williamson wrote​:

On 02/12/2014 02​:37 AM\, Steve Hay wrote​:

I was expecting it to fall back to my system default (German\, as specified in Control Panel) in this case\, exactly as like it uses if there is no LC_ALL set in the environment.

Why does it fall back to "C" instead?

Because it's a case I hadn't considered. I'll look into it

The branch now has a version that will fall back to the system default on Windows. Please try it out\, and let me know. Please also look at the pod changes to see if they are accurate and adequate.

With Control Panel set to English (United Kingdom) and LC_ALL set to XXX it works (or at the very least claims to work\, there being no difference between "C" and "English" in this case) as expected\, now falling back to the system default​:

C​:\Dev\Git\perl>perl -MPOSIX -e "print strftime('%#x'\, localtime)" perl​: warning​: Setting locale failed. perl​: warning​: Please check that your locale settings​: LC_ALL = "XXX"\, LANG = (unset) are supported and installed on your system. perl​: warning​: Falling back to the system default locale. 13 February 2014

But if I set the Control Panel to German (Germany) (and still have LC_ALL=XXX) then something odd happens​:

C​:\Dev\Git\perl>perl -MPOSIX -e "print strftime('%#x'\, localtime)" perl​: warning​: Setting locale failed. perl​: warning​: Please check that your locale settings​: LC_ALL = "XXX"\, LANG = (unset) are supported and installed on your system. perl​: warning​: Falling back to the system default locale. Invalid version format (non-numeric data) at C​:/Dev/Git/perl/lib/Exporter.pm line 3. Compilation failed in require at C​:/Dev/Git/perl/lib/Fcntl.pm line 61. Compilation failed in require at C​:/Dev/Git/perl/lib/POSIX.pm line 17. BEGIN failed--compilation aborted at C​:/Dev/Git/perl/lib/POSIX.pm line 17. Compilation failed in require. BEGIN failed--compilation aborted.

Randomly trying other languages\, it appears (I didn't go through them all) that all the English* ones work but no others.

The POD changes look fine.

Please try it with the new smoke-me version

Sorry\, this is still the same (testing 3eddf8fb44).

I abandoned trying to put bandaids on\, and refactored the code some. In doing so\, I changed it so that in general if initialization fails\, it goes to the next lower priority environment variable\, and repeats until success\, or it reaches the C locale. On Windows\, the system default is tried just before C.

Thank you. This is now working correctly for me. And all tests pass too :-)

p5pRT commented 10 years ago

From @khwilliamson

Now fixed in blead by 0e92a118111cc7fdf7a2bf58c8e45ef7b2b85ef4 -- Karl Williamson

p5pRT commented 10 years ago

@khwilliamson - Status changed from 'open' to 'resolved'