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
Gconvert() obeys LC_NUMERIC without "use locale" in 5.19.8 and 5.19.9 #13620
Comments
From calle@init.seCreated by calle@init.seCommit bc8ec7c makes Gconvert() obey Perl Info
|
From @khwilliamsonOn 02/24/2014 07:39 AM, (via RT) wrote:
I'm thinking we should revert the code changes part of that commit. The That said, the commit changes the behavior. I don't believe we are On the other hand, if we don't have to break existing code, then I don't So I'm thinking it's best to revert. |
The RT System itself - Status changed from 'new' to 'open' |
From @khwilliamsonOn Mon Feb 24 06:39:54 2014, calle@init.se wrote:
I'm wondering if you have experienced GConvert prior to 5.19 being affected by "use locale". My reading of the code indicates not. It appears to me that it generally used the dot for a decimal point no matter what the locale and regardless of "use locale". The place I know of where it could use a comma, say, stemmed from using POSIX::strod() prior to it, as strtod didn't properly clean up after itself, and 'use locale' is irrelevant. But if you know cases other than this, I would appreciate hearing about them. |
From calle@init.seOn 7 mar 2014, at 21:05, Karl Williamson via RT <perlbug-followup@perl.org> wrote:
I haven’t seen that, no. But then I’ve never actually used locales in real-life code, since I’ve found them to contribute far more problems than value. My mentioning them in the problem report was more of a “this should definitely not happen without ‘use locale’” than a statement that it should happen with it. In retrospect, that may have been more confusing than useful. -- |
From @eserteCalle Dybedahl <calle@init.se> writes:
I don't know if it's related, but there's a number of CPAN modules which The test suites of these modules fail if LC_NUMERIC is set to Regards, -- |
From calle@init.seOn 13 mar 2014, at 18:45, slaven@rezic.de via RT <perlbug-followup@perl.org> wrote:
Failing to install JSON::XS was how I noticed this in the first place, I just tried to narrow it down as far as I could before reporting it. -- |
From @pjcjOn Thu, Mar 13, 2014 at 06:39:40PM +0100, Slaven Rezic wrote:
Just for information, Devel::Cover can be added to this list: http://www.cpantesters.org/cpan/report/71ecad34-ac83-11e3-86a6-6f69e0bfc7aa -- |
From @khwilliamsonOn 03/16/2014 03:25 AM, Paul Johnson wrote:
Thanks Slaven and Paul. This is most helpful. Is there any guess as to |
From @pjcjOn Sun, Mar 16, 2014 at 08:54:37AM -0600, Karl Williamson wrote:
I only know about Devel::Cover because of the cpantesters report from Perhaps Slaven has an idea of how much of CPAN has passed through his -- |
From @khwilliamsonOn 03/16/2014 06:01 PM, Paul Johnson wrote:
First, I'd like to thank Calle for submitting this ticket, and doing the It is true that Gconvert is not listed in perlapi, so one might argue I had been leaning towards reverting this commit, but after doing more The premise of this ticket is incorrect. The commit did not change I had thought that the only way to get Gconvert to use other than the C In other words, code using Gconvert cannot expect that the decimal point A simple way to expose these bugs in earlier Perl releases is to add BEGIN { POSIX::setlocale(LC_NUMERIC, "de_DE.utf8"); } (after making sure POSIX:: is loaded). I tried this with 5.18.0 and a Now, it may be that JSON::XS is agnostic about the radix character: "if It may also be that the caller does not do anything with locale itself, This succinctly demonstrates the crux of the bug: JSON::XS shouldn't One solution to this is to wrap Gconvert, as the core now does in its My current thinking is to make the wrapping macros part of the API, and Also, we could make a pre-wrapped Gconvert that uses the C locale when I haven't looked at all the modules in the list; I know that several of |
From @khwilliamsonOn 03/17/2014 02:44 PM, Karl Williamson wrote:
And here is that message. I'm repeating a bit of the context of the The tests in this module are buggy, and again it was exposed by the The Number::Format tests do seem to think that in fact the locale is setlocale(&LC_ALL, 'en_US'); However, this is omitted from one file, format_bytes.t, and the return In researching this, I found another bug, in locale.t. It explicitly |
From @rjbs* Karl Williamson <public@khwilliamson.com> [2014-03-19T16:19:29]
Thanks for both of these enlightening messages. Your reasoning seems sound to -- |
From @khwilliamsonOn 03/30/2014 09:58 PM, Karl Williamson wrote:
Having thought about this a little more, I have yet another idea: 1) Revert the commit for 5.20. 2) In 5.21, change POSIX::setlocale() so that it always leaves the 3) This would mean that all libc calls from XS would normally get a dot 4) There are undoubtedly XS modules that depend on the radix not being 5) POSIX::strtod() has for a long time assumed that the LC_NUMERIC This would probably mean we wouldn't deprecate Gconvert, but as I |
From @khwilliamsonChanged by commit 52686f2 |
@khwilliamson - Status changed from 'open' to 'resolved' |
From kaffeetisch@gmx.deAccording to 'git bisect', commit # perl -e'use Gtk3; BEGIN{ Gtk3::init (); } use 5.8.0;' && echo OK Indirectly, this causes failures in Gtk3's test suite. A similar bug was reported in Gtk3::init is a wrapper around the C function gtk_init which for this However, in contrast to the situation prior to commit # perl -e'use POSIX qw/locale_h/; BEGIN{ setlocale (LC_ALL, ""); } use My locale environment is: LANG=en_US.UTF-8 |
From @khwilliamsonOn 06/01/2014 08:48 AM, Torsten Schoenfeld wrote:
Please see the discussion of I think that the branch at should fix this, and would appreciate it if you would try it out |
Migrated from rt.perl.org#121317 (status was 'resolved')
Searchable as RT121317$
The text was updated successfully, but these errors were encountered: