On Fri, Mar 28, 2014 at 03:41:16AM -0400, Calle Dybedahl via RT <bug-JSON-XS@rt.cpan.org> wrote:
Show quoted text> Here is a short script that demonstrates the problem (you may have to edit it to use a suitable locale for your machine). A quick test with the Perl versions I have installed at the moment shows the problem appearing somewhere between 5.14.4 and 5.16.3.
That's not the real problem. At least up to 5.18, calling POSIX::setlocale
enabling LC_NUMERIC causes a lot of issues with perl itself (and the
effect on JSON::XS is documented). For example, in 5.18, this would not
work as expected by a lot of code, printing 1 instead of 1.2:
my $x = 0.2;
print "$x"+1;
So locale breaking perl code is not a new thing. Superficially, the above
is a bug in perl, as there is no such thing as a string type or a number
type, so the stringified form must work correctly as a number.
And it's quite obvious, some vague statements to the contrary, that perl
numbers must stringify with ".", as witnessed by perlfaq4 for example,
which also breaks down:
when( /^-?(?:\d+\.?|\.\d)\d*\z/ )
{ say "\tis a real number"; continue }
when( /^[+-]?(?=\.?\d)\d*\.?\d*(?:e[+-]?\d+)?\z/i)
{ say "\tis a C float" }
The assumption that numbers stringify in a way compatible to source code
is deeply ingrained, and also very useful.
Of course, it's understandable that perl worked like this for, like 20+
years: changing the locale around stringifying numbers is not thread safe,
and very slow (I hope perl doesn't try to do that in 5.20, thraeds are too
useful to be ruled out by perl), and converting floating point numbers
yourself is not possible in portable code, so you are stuck with the libc,
which heeds the locale.
So while the real problem is the unusability if locales to solve real
problems, this problem cannot be solved.
That leaves us with perl creating such problems on it's own, and that is
perl enabling the LC_NUMERIC category with "use locale" now apparently. Or
something else to the extent. I mean, perl itself didn't work correctly
for all of its life, so why not enable it, because surely, everybody elses
code is magically going to cope with the very same problem that perl
didn't for decades.
In fact, I do not care much about what causes the problem, I do care that
basically all my bugreports about such regressions are met with either
uncivil and/or bullshit answers, or outright denial that the problem even exists.
While I will happily explain problems and report bugs, I have given up on
trying to reason with p5pers, as they have clearly given up on backwards
compatibility (and in fact, some of the former p5pers have done so, too).
So, the *real* problem is not that this happens - bugs happen. The *real*
problem is that the bug isn't immediately fixed, but instead it's always
such a fight to get regressions acknowledged, so they often end up in
releases, which is then used to argue that backwards compatibility is not
relevant anymore (which gave us, among other things, the unicode mess in
perl).
--
The choice of a Deliantra, the free code+content MORPG
-----==- _GNU_
http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / schmorp@schmorp.de
-=====/_/_//_/\_,_/ /_/\_\
