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

POSIX::localeconv: behavior change when called without POSIX::setlocale #14437

Closed
p5pRT opened this issue Jan 21, 2015 · 5 comments
Closed

POSIX::localeconv: behavior change when called without POSIX::setlocale #14437

p5pRT opened this issue Jan 21, 2015 · 5 comments

Comments

@p5pRT
Copy link

p5pRT commented Jan 21, 2015

Migrated from rt.perl.org#123649 (status was 'rejected')

Searchable as RT123649$

@p5pRT
Copy link
Author

p5pRT commented Jan 21, 2015

From @eserte

In bleadperl, if a locale is set and POSIX​::localeconv() called without a prior call to POSIX​::setlocale(), then the user's locale is used. This was not the case in perl 5.20 and earlier​:

$ env LC_ALL=de_DE.UTF-8 perl5.20.1 -MPOSIX=localeconv -e 'warn localeconv()->{decimal_point}'
. at -e line 1.
$ env LC_ALL=de_DE.UTF-8 perl5.21.8 -MPOSIX=localeconv -e 'warn localeconv()->{decimal_point}'
, at -e line 1.

Maybe this is documented somewhere in perl*delta.pod or perllocale.pod, but I could not find the place. Nevertheless this is at least surprising, because an equivalent C program would not use the user's locale unless setlocale() is explicitly called.

Regards,
  Slaven

@p5pRT
Copy link
Author

p5pRT commented Jan 22, 2015

From @khwilliamson

On 01/21/2015 01​:55 PM, slaven@​rezic.de (via RT) wrote​:

# New Ticket Created by slaven@​rezic.de
# Please include the string​: [perl #123649]
# in the subject line of all future correspondence about this issue.
# <URL​: https://rt-archive.perl.org/perl5/Ticket/Display.html?id=123649 >

In bleadperl, if a locale is set and POSIX​::localeconv() called without a prior call to POSIX​::setlocale(), then the user's locale is used. This was not the case in perl 5.20 and earlier​:

$ env LC_ALL=de_DE.UTF-8 perl5.20.1 -MPOSIX=localeconv -e 'warn localeconv()->{decimal_point}'
. at -e line 1.
$ env LC_ALL=de_DE.UTF-8 perl5.21.8 -MPOSIX=localeconv -e 'warn localeconv()->{decimal_point}'
, at -e line 1.

Maybe this is documented somewhere in perl*delta.pod or perllocale.pod, but I could not find the place. Nevertheless this is at least surprising, because an equivalent C program would not use the user's locale unless setlocale() is explicitly called.

Regards,
Slaven

The documentation is in perllocale​:

Not within the scope of "use locale"
  Only certain operations originating outside Perl should be
affected, as follows​:

  · ...

  · Also Perl gives access to various C library functions
through the POSIX module. Some of those functions are always affected
by the current locale. For example,
  "POSIX​::strftime()" uses "LC_TIME"; "POSIX​::strtod()"
uses "LC_NUMERIC"; "POSIX​::strcoll()" and "POSIX​::strxfrm()" use
"LC_COLLATE"; and character classification
  functions like "POSIX​::isalnum()" use "LC_CTYPE". All
such functions will behave according to the current underlying locale,
even if that locale isn't exposed to
  Perl space.

I think the text there should be clarified, though. "Some of those
functions are always affected by the current locale." is more clearly
stated as "Those functions that are locale-sensitive will always be
affected by the current locale".

I'm not sure what to do about this. The situation earlier was that some
of the locale-sensitive POSIX functions always looked at the underlying
locale, and some didn't. This inconsistency is crazy. Now, all but two
(and they are deprecated) always follow the program's underlying locale.
  localeconv() changed to be consistent, and IIRC there were modules
which were expecting it to behave the new way.

Actually, the difference between a C program and a Perl one isn't what
you stated, it is that Perl initializes with a setlocale() to the
environment, and a C program does not. In looking at the few modules
that were broken by this change, I was puzzled how the authors thought
that doing a setlocale() would change what localeconv() operated under
when they didn't also do a 'use locale'. And now it makes sense to me.
  The authors were expecting a C-like environment, where the locale is
"C" until changed by a setlocale. The authors think that localeconv()
should get the current locale without having to say 'use locale', and
that is now the operation of Perl. What they didn't realize was that
Perl may start them up in a non-C locale.

I suppose it would be possible to change Perl to meet that expectation,
but I don't know how many modules work the other way.

@p5pRT
Copy link
Author

p5pRT commented Jan 22, 2015

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

@p5pRT
Copy link
Author

p5pRT commented Aug 6, 2016

From @khwilliamson

The behavior is now consistent, and we haven't had further problems noted. So, I'm rejecting this ticket
--
Karl Williamson

@p5pRT
Copy link
Author

p5pRT commented Aug 6, 2016

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

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

No branches or pull requests

1 participant