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
Comments
From andrew@pimlott.ne.mediaone.netI'm trying to understand Perl's traditional locale support, and finding it #!/usr/bin/perl use locale; and ran it in the debugger with LANG=en_US. The transcript is at the end, My locale support seems to work fine with a simple C program such as #include <locale.h> main() Andrew PS. This message is in ISO-8859-1; the character 0xc0 is "LATIN CAPITAL % LANG=en_US perl -d ./try2 Loading DB routines from perl5db.pl version 1.0402 Enter h or `h h' for help. main::(./try2:5): $c1 = chr 0xc0; Perl Info
|
From [Unknown Contact. See original ticket]<andrew@pimlott.ne.mediaone.net> writes:
Because you have not called POSIX's setlocale() (I am not 100% sure
If I recall correctly use locale;
It is also far from uncommon for 'en_US' locales to claim that they are But as your C program works that seems not to be the problem. |
From [Unknown Contact. See original ticket]I'll tell what I found out, then answer what Nick says because it To recap, the problem was that lc honors locale (under "use The reason is that isalpha is implemented as .xs code, while tolower I think this raises some fundamental issues, but I'm not sure It also seems clear that XS code should not always run in the Now, to respond to Nick: On Sun, Feb 25, 2001 at 10:34:42PM +0000, nick@ing-simmons.net wrote:
The perllocale documentation describes setlocale as fully At any rate, calling 'setlocale LC_ALL, "en_US";' didn't change
Duh, sorry. I'm not going to guess how the debugger accesses On the other hand, the debugger not assuming the scope of the
Yes, I am certain from testing and by looking at the locale source Andrew |
From @simoncozensOn Mon, Feb 26, 2001 at 06:31:50PM -0500, Andrew Pimlott wrote:
Urgh, that's a bug. tolower in POSIX should call the underlying C routine. |
From [Unknown Contact. See original ticket]On Mon, Feb 26, 2001 at 11:44:27PM +0000, Simon Cozens wrote:
Ok, the question is how many functions in POSIX.pm need to be As for which ones need to be in C for locale purposes, aside from Andrew |
From [Unknown Contact. See original ticket]On Mon, Feb 26, 2001 at 07:13:48PM -0500, Andrew Pimlott wrote:
FWIW, I took a quick look at this but gave up. For toupper and Andrew |
From @jhiOn Fri, Mar 02, 2001 at 10:15:06AM -0500, Andrew Pimlott wrote:
I'm somewhat interested, but 100%, I dunno, that means being fully
|
From [Unknown Contact. See original ticket]On Fri, Mar 02, 2001 at 09:21:41AM -0600, Jarkko Hietaniemi wrote:
Hmm, looks like I missed an essential point: locale support is not It is only where (core) perl has a choice between calling a perllocale is not at all clear on this; I expected that without "use This pragma tells the compiler to enable (or disable) the use of Should we take that as the law of the land? In that case, the only Andrew |
From @jkeenanOn Fri Mar 02 10:29:21 2001, RT_System 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 Thank you very much. |
From @khwilliamsonOn 01/30/2012 07:34 PM, James E Keenan via RT wrote:
I wonder why we call setlocale unconditionally. Why not call it upon There are no comments as to why it's always called and I did not see |
From @khwilliamsonOn Wed Feb 01 09:39:52 2012, public@khwilliamson.com wrote:
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 So the question is do we fix these or deprecate them? |
From @rjbs* Karl Williamson via RT <perlbug-followup@perl.org> [2014-02-18T20:18:46]
I can't come up with a good reason to fix rather than deprecate. -- |
From @jkeenanOn Sun Feb 23 12:26:43 2014, perl.p5p@rjbs.manxome.org wrote:
Can we now move forward with the deprecation? Thank you very much. |
From @khwilliamsonOn 03/03/2014 06:01 PM, James E Keenan via RT wrote:
It's too late for 5.20 |
From @khwilliamsonOn 03/03/2014 08:28 PM, Karl Williamson wrote:
But actually, there may be a reason to fix and not deprecate, and that |
From @jkeenanTwo-and-a-half years ago, I wrote: On Mon Jan 30 18:34:57 2012, jkeenan wrote:
Subsequently, Karl Williamson wrote:
When I later asked:
Karl commented further:
Can we move toward a resolution of this 13-1/2-year-old ticket? Suggestions? Patches? Thank you very much. -- |
From @khwilliamsonOn 10/19/2014 05:42 PM, James E Keenan via RT wrote:
I have been planning and still do plan on getting to this in 5.21. It's |
From @khwilliamsonI'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. .-- |
From @khwilliamsonNow reverted as a1ff81be13b3be033eb290d743c82381140008ab. I'll reinstate it plus your patch in early 5.25. |
@khwilliamson - Status changed from 'open' to 'resolved' |
From @khwilliamsonOops, I used a message intended for a different ticket. This ticket is hereby reopened, albeit briefly |
@khwilliamson - Status changed from 'resolved' to 'open' |
From @khwilliamsonThe 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. |
@khwilliamson - Status changed from 'open' to 'pending release' |
From @khwilliamsonThank you for submitting this report. You have helped make Perl better. Perl 5.24.0 may be downloaded via https://metacpan.org/release/RJBS/perl-5.24.0 |
@khwilliamson - Status changed from 'pending release' to 'resolved' |
Migrated from rt.perl.org#5907 (status was 'resolved')
Searchable as RT5907$
The text was updated successfully, but these errors were encountered: