Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

inconsistencies in locale support #3480

Closed
p5pRT opened this issue Feb 25, 2001 · 26 comments
Closed

inconsistencies in locale support #3480

p5pRT opened this issue Feb 25, 2001 · 26 comments

Comments

@p5pRT
Copy link

p5pRT commented Feb 25, 2001

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

Searchable as RT5907$

@p5pRT
Copy link
Author

p5pRT commented Feb 25, 2001

From andrew@pimlott.ne.mediaone.net

I'm trying to understand Perl's traditional locale support, and finding it
frustratingly inconsistent. I created the following program

#!/usr/bin/perl

use locale;
use POSIX;
$c1 = chr 0xc0;
$c2 = tolower $c1;
$c3 = lc $c1;
__END__

and ran it in the debugger with LANG=en_US. The transcript is at the end,
but in short, tolower always returns the same character, and lc works as
expected in the program, but not on the debugger command line. The POSIX
documentation says that tolower is identical to lc, and neither the POSIX
nor perldebug documentation mention any interaction between locales and the
debugger.

My locale support seems to work fine with a simple C program such as

#include <locale.h>

main()
{
  unsigned char c = 0xc0;
  unsigned char c2;
  setlocale (LC_ALL, "");
  c2 = tolower(c);
  printf("%c (%x) -> %c (%x)\n", c, c, c2, c2);
}

Andrew

PS. This message is in ISO-8859-1; the character 0xc0 is "LATIN CAPITAL
LETTER A WITH GRAVE", and 0xe0 is "LATIN SMALL LETTER A WITH GRAVE".

% LANG=en_US perl -d ./try2

Loading DB routines from perl5db.pl version 1.0402
Emacs support available.

Enter h or `h h' for help.

main​::(./try2​:5)​: $c1 = chr 0xc0;
  DB<1> n
main​::(./try2​:6)​: $c2 = tolower $c1;
  DB<1>
main​::(./try2​:7)​: $c3 = lc $c1;
  DB<1>
Debugged program terminated. Use q to quit or R to restart,
  use O inhibit_exit to avoid stopping after program termination,
  h q, h R or h O to get additional info.
  DB<1> x $c1
0 'À'
  DB<2> x $c2
0 'À'
  DB<3> x $c3
0 'à'
  DB<4> x tolower $c1
0 'À'
  DB<5> x lc $c1
0 'À'
  DB<6> q

Perl Info


Site configuration information for perl 5.00503:

Configured by drow at Sun Apr 30 12:07:23 EDT 2000.

Summary of my perl5 (5.0 patchlevel 5 subversion 3) configuration:
  Platform:
    osname=linux, osvers=2.2.15pre14, archname=i386-linux
    uname='linux them 2.2.15pre14 #2 smp mon mar 13 14:29:00 est 2000 i686 unknown '
    hint=recommended, useposix=true, d_sigaction=define
    usethreads=undef useperlio=undef d_sfio=undef
  Compiler:
    cc='cc', optimize='-O2 ', gccversion=2.95.2 20000313 (Debian GNU/Linux)
    cppflags='-Dbool=char -DHAS_BOOL -D_REENTRANT -DDEBIAN -I/usr/local/include'
    ccflags ='-Dbool=char -DHAS_BOOL -D_REENTRANT -DDEBIAN -I/usr/local/include'
    stdchar='char', d_stdstdio=undef, usevfork=false
    intsize=4, longsize=4, ptrsize=4, doublesize=8
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
    alignbytes=4, usemymalloc=n, prototype=define
  Linker and Libraries:
    ld='cc', ldflags =' -L/usr/local/lib'
    libpth=/usr/local/lib /lib /usr/lib
    libs=-lnsl -lndbm -lgdbm -ldbm -ldb -ldl -lm -lc -lposix -lcrypt
    libc=, so=so, useshrplib=false, libperl=libperl.a
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic'
    cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib'

Locally applied patches:
    


@INC for perl 5.00503:
    /home/andrew/local/lib/perl5
    /usr/lib/perl5/5.005/i386-linux
    /usr/lib/perl5/5.005
    /usr/local/lib/site_perl/i386-linux
    /usr/local/lib/site_perl
    /usr/lib/perl5
    .


Environment for perl 5.00503:
    HOME=/home/andrew
    LANG (unset)
    LANGUAGE (unset)
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/home/andrew/bin:/usr/sbin:/sbin:/usr/bin:/bin:/usr/sbin:/sbin
    PERL5LIB=/home/andrew/local/lib/perl5
    PERL_BADLANG (unset)
    SHELL=/usr/bin/zsh

@p5pRT
Copy link
Author

p5pRT commented Feb 25, 2001

From [Unknown Contact. See original ticket]

<andrew@​pimlott.ne.mediaone.net> writes​:

This is a bug report for perl from andrew@​pimlott.ne.mediaone.net,
generated with the help of perlbug 1.26 running under perl 5.00503.

-----------------------------------------------------------------
[Please enter your report here]

I'm trying to understand Perl's traditional locale support, and finding it
frustratingly inconsistent. I created the following program

#!/usr/bin/perl

use locale;
use POSIX;
$c1 = chr 0xc0;
$c2 = tolower $c1;
$c3 = lc $c1;
__END__

and ran it in the debugger with LANG=en_US. The transcript is at the end,
but in short, tolower always returns the same character,

Because you have not called POSIX's setlocale() (I am not 100% sure
we support it.)

and lc works as
expected in the program, but not on the debugger command line.

If I recall correctly

use locale;
is lexically scoped, and debugger is in a different scope.

PS. This message is in ISO-8859-1; the character 0xc0 is "LATIN CAPITAL
LETTER A WITH GRAVE", and 0xe0 is "LATIN SMALL LETTER A WITH GRAVE".

% LANG=en_US perl -d ./try2

It is also far from uncommon for 'en_US' locales to claim that they are
ASCII only - (and that true Americans don't need no nasty pinko accented
characters ;-))

But as your C program works that seems not to be the problem.

@p5pRT
Copy link
Author

p5pRT commented Feb 26, 2001

From [Unknown Contact. See original ticket]

I'll tell what I found out, then answer what Nick says because it
(too) raises interesting points.

To recap, the problem was that lc honors locale (under "use
locale"), but POSIX​::tolower does not. Interestingly,
POSIX​::isalpha does honor locale. You can test this trivially by
comparing the result of lc, tolower, and isalpha on chr 0xc0, in the
"C" (ASCII) locale versus the en_US locale (assuming your en_US
locale is ISO-8859-1, as it is by default under GNU libc).

The reason is that isalpha is implemented as .xs code, while tolower
is a pure Perl subroutine that calls lc. Apparently, the xs code is
executed in the same lexical context as the calling code, while
tolower obviously is not.

I think this raises some fundamental issues, but I'm not sure
exactly which. It seems clear that one would like to be able to
write a correct tolower (ie, exactly equivalent to lc, as per the
POSIX documentation) in pure Perl. One possibility is a TCL-like
"uplevel", but I desperately hope that doesn't turn out to be the
best option. Another is to have dynamically scoped pramata.
Another is to have a way to explicitly make a pragma dynamic, eg
"use :dynamically locale". Anything better?

It also seems clear that XS code should not always run in the
lexical context of the caller, because I'm sure that there are cases
in which inheriting pramata would be wrong or at least confusing
(action at a distance). But I'm sure this have performance
implications.

Now, to respond to Nick​:

On Sun, Feb 25, 2001 at 10​:34​:42PM +0000, nick@​ing-simmons.net wrote​:

Because you have not called POSIX's setlocale() (I am not 100% sure
we support it.)

The perllocale documentation describes setlocale as fully
functional, but also mentions that it is only necessary if the
relevant environment variables are not set. Grep for "one of the
following must be true".

At any rate, calling 'setlocale LC_ALL, "en_US";' didn't change
anything.

and lc works as
expected in the program, but not on the debugger command line.

If I recall correctly

use locale;
is lexically scoped, and debugger is in a different scope.

Duh, sorry. I'm not going to guess how the debugger accesses
lexical variables (someday I'll have the courage to look) ...

On the other hand, the debugger not assuming the scope of the
current line of code is very arguably a bug, especially since it
does have access to lexical variables.

It is also far from uncommon for 'en_US' locales to claim that they are
ASCII only - (and that true Americans don't need no nasty pinko accented
characters ;-))

But as your C program works that seems not to be the problem.

Yes, I am certain from testing and by looking at the locale source
that the en_US locale uses ISO-8859-1.

Andrew

@p5pRT
Copy link
Author

p5pRT commented Feb 26, 2001

From @simoncozens

On Mon, Feb 26, 2001 at 06​:31​:50PM -0500, Andrew Pimlott wrote​:

The reason is that isalpha is implemented as .xs code, while tolower
is a pure Perl subroutine that calls lc.

Urgh, that's a bug. tolower in POSIX should call the underlying C routine.
POSIX.pm things should be POSIXish first and Perlish second.

@p5pRT
Copy link
Author

p5pRT commented Feb 26, 2001

From [Unknown Contact. See original ticket]

On Mon, Feb 26, 2001 at 11​:44​:27PM +0000, Simon Cozens wrote​:

On Mon, Feb 26, 2001 at 06​:31​:50PM -0500, Andrew Pimlott wrote​:

The reason is that isalpha is implemented as .xs code, while tolower
is a pure Perl subroutine that calls lc.

Urgh, that's a bug. tolower in POSIX should call the underlying C routine.
POSIX.pm things should be POSIXish first and Perlish second.

Ok, the question is how many functions in POSIX.pm need to be
migrated? Quite a number are implemented as Perl. Only a few do
anything non-trivial, so migrating them all to C is certainly
feasible.

As for which ones need to be in C for locale purposes, aside from
tolower and toupper, the only candidates I see (that is actually
implemented) is strerror. But I may have missed some, and maybe
there are some others that have subtle bugs due to being implemented
in Perl?

Andrew

@p5pRT
Copy link
Author

p5pRT commented Mar 2, 2001

From [Unknown Contact. See original ticket]

On Mon, Feb 26, 2001 at 07​:13​:48PM -0500, Andrew Pimlott wrote​:

On Mon, Feb 26, 2001 at 11​:44​:27PM +0000, Simon Cozens wrote​:

On Mon, Feb 26, 2001 at 06​:31​:50PM -0500, Andrew Pimlott wrote​:

The reason is that isalpha is implemented as .xs code, while tolower
is a pure Perl subroutine that calls lc.

Urgh, that's a bug. tolower in POSIX should call the underlying C routine.
POSIX.pm things should be POSIXish first and Perlish second.

As for which ones need to be in C for locale purposes, aside from
tolower and toupper, the only candidate I see (that is actually
implemented) is strerror.

FWIW, I took a quick look at this but gave up. For toupper and
tolower, I thought I could just make them aliases to CORE​::uc and
CORE​::lc, but I discovered you can't do that in Perl, and I'm not up
to figuring out the XS method. For strerror, I discovered that it
already "works", but only because locale is not properly lexically
scoped. That is, there are many places where perl must call
locale-aware C functions (like strerror()), but perl doesn't turn on
and off C locale support (with setlocale()) by locale scope. (I
infer from this that nobody's interested in getting locale support
100% right anyway.)

Andrew

@p5pRT
Copy link
Author

p5pRT commented Mar 2, 2001

From @jhi

On Fri, Mar 02, 2001 at 10​:15​:06AM -0500, Andrew Pimlott wrote​:

On Mon, Feb 26, 2001 at 07​:13​:48PM -0500, Andrew Pimlott wrote​:

On Mon, Feb 26, 2001 at 11​:44​:27PM +0000, Simon Cozens wrote​:

On Mon, Feb 26, 2001 at 06​:31​:50PM -0500, Andrew Pimlott wrote​:

The reason is that isalpha is implemented as .xs code, while tolower
is a pure Perl subroutine that calls lc.

Urgh, that's a bug. tolower in POSIX should call the underlying C routine.
POSIX.pm things should be POSIXish first and Perlish second.

As for which ones need to be in C for locale purposes, aside from
tolower and toupper, the only candidate I see (that is actually
implemented) is strerror.

FWIW, I took a quick look at this but gave up. For toupper and
tolower, I thought I could just make them aliases to CORE​::uc and
CORE​::lc, but I discovered you can't do that in Perl, and I'm not up
to figuring out the XS method. For strerror, I discovered that it
already "works", but only because locale is not properly lexically
scoped. That is, there are many places where perl must call
locale-aware C functions (like strerror()), but perl doesn't turn on
and off C locale support (with setlocale()) by locale scope. (I
infer from this that nobody's interested in getting locale support
100% right anyway.)

I'm somewhat interested, but 100%, I dunno, that means being fully
compliant with a buggy concept and usually a buggy implementation of
that buggy concept, I dunno whether that's a lofty goal... If you can
point out some of the spots where setlocale() acrobatics would be
needed, I can take a look them.

Andrew

@p5pRT
Copy link
Author

p5pRT commented Mar 2, 2001

From [Unknown Contact. See original ticket]

On Fri, Mar 02, 2001 at 09​:21​:41AM -0600, Jarkko Hietaniemi wrote​:

If you can
point out some of the spots where setlocale() acrobatics would be
needed, I can take a look them.

Hmm, looks like I missed an essential point​: locale support is not
dependent on 'use locale' at all! This seems to be intentional.
perl unconditionally calls setlocale() on startup, and never calls
it again (unless you use POSIX​::setlocale() explictly). So
POSIX​::isalpha() respects $LANG by default, even if you never
mention the locale pragma.

It is only where (core) perl has a choice between calling a
locale-sensitive libc function, and doing things its own way (eg,
hard-coding character semantics), that the locale pragma currently
matters. Since the string value of $! requires calling a
locale-sensitive function (strerror()), $! always respects locale.

perllocale is not at all clear on this; I expected that without "use
locale", the locale system would never be initialized. However, the
locale.pm doc says what seems to be the intent​:

  This pragma tells the compiler to enable (or disable) the use of
  POSIX locales for built-in operations

Should we take that as the law of the land? In that case, the only
bug I know about is $! . (Possibly also $^E .) setlocale()
acrobatics are the obvious solution. I will poke around for more if
the above rule is agreed upon.

Andrew

@p5pRT
Copy link
Author

p5pRT commented Jan 31, 2012

From @jkeenan

On Fri Mar 02 10​:29​:21 2001, RT_System wrote​:

On Fri, Mar 02, 2001 at 09​:21​:41AM -0600, Jarkko Hietaniemi wrote​:

If you can
point out some of the spots where setlocale() acrobatics would be
needed, I can take a look them.

Hmm, looks like I missed an essential point​: locale support is not
dependent on 'use locale' at all! This seems to be intentional.
perl unconditionally calls setlocale() on startup, and never calls
it again (unless you use POSIX​::setlocale() explictly). So
POSIX​::isalpha() respects $LANG by default, even if you never
mention the locale pragma.

It is only where (core) perl has a choice between calling a
locale-sensitive libc function, and doing things its own way (eg,
hard-coding character semantics), that the locale pragma currently
matters. Since the string value of $! requires calling a
locale-sensitive function (strerror()), $! always respects locale.

perllocale is not at all clear on this; I expected that without "use
locale", the locale system would never be initialized. However, the
locale.pm doc says what seems to be the intent​:

This pragma tells the compiler to enable \(or disable\) the use of
POSIX locales for built\-in operations

Should we take that as the law of the land? In that case, the only
bug I know about is $! . (Possibly also $^E .) setlocale()
acrobatics are the obvious solution. I will poke around for more if
the above rule is agreed upon.

Andrew

There has been no movement on this ticket for nearly eleven years.

Does anyone feel we are in need of the "setlocale acrobatics" discussed
in this ticket? If so, then we should probably outline those in a new
RT. If not, we should close the ticket.

Thank you very much.
Jim Keenan

@p5pRT
Copy link
Author

p5pRT commented Feb 1, 2012

From @khwilliamson

On 01/30/2012 07​:34 PM, James E Keenan via RT wrote​:

On Fri Mar 02 10​:29​:21 2001, RT_System wrote​:

On Fri, Mar 02, 2001 at 09​:21​:41AM -0600, Jarkko Hietaniemi wrote​:

If you can
point out some of the spots where setlocale() acrobatics would be
needed, I can take a look them.

Hmm, looks like I missed an essential point​: locale support is not
dependent on 'use locale' at all! This seems to be intentional.
perl unconditionally calls setlocale() on startup, and never calls
it again (unless you use POSIX​::setlocale() explictly). So
POSIX​::isalpha() respects $LANG by default, even if you never
mention the locale pragma.

It is only where (core) perl has a choice between calling a
locale-sensitive libc function, and doing things its own way (eg,
hard-coding character semantics), that the locale pragma currently
matters. Since the string value of $! requires calling a
locale-sensitive function (strerror()), $! always respects locale.

perllocale is not at all clear on this; I expected that without "use
locale", the locale system would never be initialized. However, the
locale.pm doc says what seems to be the intent​:

 This pragma tells the compiler to enable \(or disable\) the use of
 POSIX locales for built\-in operations

Should we take that as the law of the land? In that case, the only
bug I know about is $! . (Possibly also $^E .) setlocale()
acrobatics are the obvious solution. I will poke around for more if
the above rule is agreed upon.

Andrew

There has been no movement on this ticket for nearly eleven years.

Does anyone feel we are in need of the "setlocale acrobatics" discussed
in this ticket? If so, then we should probably outline those in a new
RT. If not, we should close the ticket.

Thank you very much.
Jim Keenan

---
via perlbug​: queue​: perl5 status​: open
https://rt-archive.perl.org/perl5/Ticket/Display.html?id=5907

I wonder why we call setlocale unconditionally. Why not call it upon
the first encountered 'use locale'? That would solve this problem and
others I've heard about.

There are no comments as to why it's always called and I did not see
anything in the commit messages

@p5pRT
Copy link
Author

p5pRT commented Feb 19, 2014

From @khwilliamson

On Wed Feb 01 09​:39​:52 2012, public@​khwilliamson.com wrote​:

On 01/30/2012 07​:34 PM, James E Keenan via RT wrote​:

On Fri Mar 02 10​:29​:21 2001, RT_System wrote​:

On Fri, Mar 02, 2001 at 09​:21​:41AM -0600, Jarkko Hietaniemi wrote​:

If you can
point out some of the spots where setlocale() acrobatics would be
needed, I can take a look them.

Hmm, looks like I missed an essential point​: locale support is not
dependent on 'use locale' at all! This seems to be intentional.
perl unconditionally calls setlocale() on startup, and never calls
it again (unless you use POSIX​::setlocale() explictly). So
POSIX​::isalpha() respects $LANG by default, even if you never
mention the locale pragma.

It is only where (core) perl has a choice between calling a
locale-sensitive libc function, and doing things its own way (eg,
hard-coding character semantics), that the locale pragma currently
matters. Since the string value of $! requires calling a
locale-sensitive function (strerror()), $! always respects locale.

perllocale is not at all clear on this; I expected that without "use
locale", the locale system would never be initialized. However, the
locale.pm doc says what seems to be the intent​:

 This pragma tells the compiler to enable \(or disable\) the use of
 POSIX locales for built\-in operations

Should we take that as the law of the land? In that case, the only
bug I know about is $! . (Possibly also $^E .) setlocale()
acrobatics are the obvious solution. I will poke around for more if
the above rule is agreed upon.

Andrew

There has been no movement on this ticket for nearly eleven years.

Does anyone feel we are in need of the "setlocale acrobatics" discussed
in this ticket? If so, then we should probably outline those in a new
RT. If not, we should close the ticket.

Thank you very much.
Jim Keenan

---
via perlbug​: queue​: perl5 status​: open
https://rt-archive.perl.org/perl5/Ticket/Display.html?id=5907

I wonder why we call setlocale unconditionally. Why not call it upon
the first encountered 'use locale'? That would solve this problem and
others I've heard about.

There are no comments as to why it's always called and I did not see
anything in the commit messages

The partial answer to this is from Jarkko, "Because setlocale() depends on the environment variables and they may change during the lifetime of a process."

But that doesn't explain why the environment couldn't just be queried at start-up and the results cached until actually needed. Jarkko also thinks the whole locale thing should be ripped out. I could see doing that if and when CLDR support is added.

But things have been cleaned up for 5.20. 'use locale' is required for locale to be visible to Perl space, but not to POSIX​:: space. The POSIX​::isfoo functions are now
deprecated, instead of fixing their bugs. The one remaining issue I see in this ticket is the POSIX​::toupper and :​:tolower functions don't respect locale, unlike the other POSIX functions. This is trivial to change, but I'm not sure we shouldn't just deprecate these as well; they have behaved identically to uc() and lc() for some time, except that the latter can be made to respect locale.

So the question is do we fix these or deprecate them?
--
Karl Williamson

@p5pRT
Copy link
Author

p5pRT commented Feb 23, 2014

From @rjbs

* Karl Williamson via RT <perlbug-followup@​perl.org> [2014-02-18T20​:18​:46]

So the question is do we fix these or deprecate them?

I can't come up with a good reason to fix rather than deprecate.

--
rjbs

@p5pRT
Copy link
Author

p5pRT commented Mar 4, 2014

From @jkeenan

On Sun Feb 23 12​:26​:43 2014, perl.p5p@​rjbs.manxome.org wrote​:

* Karl Williamson via RT <perlbug-followup@​perl.org> [2014-02-18T20​:18​:46]

So the question is do we fix these or deprecate them?

I can't come up with a good reason to fix rather than deprecate.

Can we now move forward with the deprecation?

Thank you very much.
Jim Keenan

@p5pRT
Copy link
Author

p5pRT commented Mar 4, 2014

From @khwilliamson

On 03/03/2014 06​:01 PM, James E Keenan via RT wrote​:

On Sun Feb 23 12​:26​:43 2014, perl.p5p@​rjbs.manxome.org wrote​:

* Karl Williamson via RT <perlbug-followup@​perl.org> [2014-02-18T20​:18​:46]

So the question is do we fix these or deprecate them?

I can't come up with a good reason to fix rather than deprecate.

Can we now move forward with the deprecation?

It's too late for 5.20

@p5pRT
Copy link
Author

p5pRT commented Mar 6, 2014

From @khwilliamson

On 03/03/2014 08​:28 PM, Karl Williamson wrote​:

On 03/03/2014 06​:01 PM, James E Keenan via RT wrote​:

On Sun Feb 23 12​:26​:43 2014, perl.p5p@​rjbs.manxome.org wrote​:

* Karl Williamson via RT <perlbug-followup@​perl.org>
[2014-02-18T20​:18​:46]

So the question is do we fix these or deprecate them?

I can't come up with a good reason to fix rather than deprecate.

Can we now move forward with the deprecation?

It's too late for 5.20

But actually, there may be a reason to fix and not deprecate, and that
is fixing is trivial, that is, it's less work in the short term than
deprecating.

@p5pRT
Copy link
Author

p5pRT commented Oct 19, 2014

From @jkeenan

Two-and-a-half years ago, I wrote​:

On Mon Jan 30 18​:34​:57 2012, jkeenan wrote​:

There has been no movement on this ticket for nearly eleven years.

Does anyone feel we are in need of the "setlocale acrobatics" discussed
in this ticket? If so, then we should probably outline those in a new
RT. If not, we should close the ticket.

Subsequently, Karl Williamson wrote​:

[T]hings have been cleaned up for 5.20. 'use locale' is required
for locale to be visible to Perl space, but not to POSIX​:: space. The
POSIX​::isfoo functions are now
deprecated, instead of fixing their bugs. The one remaining issue I
see in this ticket is the POSIX​::toupper and :​:tolower functions don't
respect locale, unlike the other POSIX functions. This is trivial to
change, but I'm not sure we shouldn't just deprecate these as well;
they have behaved identically to uc() and lc() for some time, except
that the latter can be made to respect locale.

So the question is do we fix these or deprecate them?

When I later asked​:

Can we now move forward with the deprecation?

Karl commented further​:

But actually, there may be a reason to fix and not deprecate, and that
is fixing is trivial, that is, it's less work in the short term than
deprecating.

Can we move toward a resolution of this 13-1/2-year-old ticket? Suggestions? Patches?

Thank you very much.

--
James E Keenan (jkeenan@​cpan.org)

@p5pRT
Copy link
Author

p5pRT commented Oct 21, 2014

From @khwilliamson

On 10/19/2014 05​:42 PM, James E Keenan via RT wrote​:

Two-and-a-half years ago, I wrote​:

On Mon Jan 30 18​:34​:57 2012, jkeenan wrote​:

There has been no movement on this ticket for nearly eleven years.

Does anyone feel we are in need of the "setlocale acrobatics" discussed
in this ticket? If so, then we should probably outline those in a new
RT. If not, we should close the ticket.

Subsequently, Karl Williamson wrote​:

[T]hings have been cleaned up for 5.20. 'use locale' is required
for locale to be visible to Perl space, but not to POSIX​:: space. The
POSIX​::isfoo functions are now
deprecated, instead of fixing their bugs. The one remaining issue I
see in this ticket is the POSIX​::toupper and :​:tolower functions don't
respect locale, unlike the other POSIX functions. This is trivial to
change, but I'm not sure we shouldn't just deprecate these as well;
they have behaved identically to uc() and lc() for some time, except
that the latter can be made to respect locale.

So the question is do we fix these or deprecate them?

When I later asked​:

Can we now move forward with the deprecation?

Karl commented further​:

But actually, there may be a reason to fix and not deprecate, and that
is fixing is trivial, that is, it's less work in the short term than
deprecating.

Can we move toward a resolution of this 13-1/2-year-old ticket? Suggestions? Patches?

Thank you very much.

I have been planning and still do plan on getting to this in 5.21. It's
trivial to fix it, and I'm tempted to, given the dearth of interest in
this. But a reply to my proposal to fix things like POSIX​::isalnum()
was that we shouldn't be changing the behavior of very old functions
like this because we might break some very old code. Better to
deprecated (which might still break that code, by yielding unexpected
output, but that can easily be silenced.

@p5pRT
Copy link
Author

p5pRT commented Mar 8, 2016

From @khwilliamson

I'm not sure what to do with this ticket now The POSIX​::isfoo() functions are gone in blead now. But the original ticket referred to tolower and toupper. Both were never deprecated, and now the documentation accurately describes their behavior​: that the current locale does not affect the results.

I'm inclined to close this ticket, and leave things as they are. I suppose we could deprecate these two functions, but it is kind of a pain to do that, and I suspect that is why it didn't happen earlier, when the other functions got deprecated. (Also they behaved better than those functions that are now gone.)

So unless I hear otherwise in, say a month, I'll close this ticket.

.--
Karl Williamson

@p5pRT
Copy link
Author

p5pRT commented Apr 8, 2016

From @khwilliamson

Now reverted as a1ff81be13b3be033eb290d743c82381140008ab. I'll reinstate it plus your patch in early 5.25.
--
Karl Williamson

@p5pRT
Copy link
Author

p5pRT commented Apr 8, 2016

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

@p5pRT
Copy link
Author

p5pRT commented Apr 8, 2016

From @khwilliamson

Oops, I used a message intended for a different ticket. This ticket is hereby reopened, albeit briefly
--
Karl Williamson

@p5pRT
Copy link
Author

p5pRT commented Apr 8, 2016

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

@p5pRT
Copy link
Author

p5pRT commented Apr 8, 2016

From @khwilliamson

The isFOO() macros will be removed as of 5.24, and as per the message on this ticket a month ago, I'm now closing it as no one objected.
--
Karl Williamson

@p5pRT
Copy link
Author

p5pRT commented Apr 8, 2016

@khwilliamson - Status changed from 'open' to 'pending release'

@p5pRT
Copy link
Author

p5pRT commented May 13, 2016

From @khwilliamson

Thank you for submitting this report. You have helped make Perl better.
 
With the release of Perl 5.24.0 on May 9, 2016, this and 149 other issues have been resolved.

Perl 5.24.0 may be downloaded via https://metacpan.org/release/RJBS/perl-5.24.0

@p5pRT p5pRT closed this as completed May 13, 2016
@p5pRT
Copy link
Author

p5pRT commented May 13, 2016

@khwilliamson - Status changed from 'pending release' to 'resolved'

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant