Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
This is a bug report for perl from email@example.com,
I get the following test failures on a ppc machine running debian wheezy,
not ok 3467
not ok 3461
There's another test script in the same directory that fails with
The failure arises because perl sets the value 1e+129 incorrectly. Unpacking
In the correct representation, I think the trailing 6 bits are discarded
In base 2, correct form is:
whereas, perl assigns:
If perl assigned correctly then these tests would pass, as is.
The same failures on this platform occurred during 'make test' for 5.18.1.
I've seen mention of using POSIX::strtod to assign to NVs correctly.
Site configuration information for perl 5.19.6:
Configured by sisyphus-sis at Wed Dec 4 00:45:28 EST 2013.
Summary of my perl5 (revision 5 version 19 subversion 6) configuration:
@INC for perl 5.19.6:
Environment for perl 5.19.6:
On Wed, 11 Dec 2013 10:19:03 GMT, sisyphus wrote:
1. Does this problem still exist?
2. Am I correct in thinking that it's specific to the ppc64 architecture? (I can't reproduce it on x86_64-linux-ld.)
Thank you very much.
Yes, I think it's still there with 5.25.8. I see occurrences of 1e+129 in
Yes, I think so.
$ perl -V:longdblkind
It's hard to find a value of the form "1e+X" (where X is in the vicinity of
$ perl -le '$x = 1e+129;print $x'
I haven't seen anyone confirm the error, though there probably aren't a
On Wed, 11 Dec 2013 02:19:03 -0800, sisyphus wrote:
Actually, I don't think 5ab7151b377c247e5707b80b00474440 is correct either.
Having spent some time tonight playing around with various ad-hoc values, it seems that strtold() is little more reliable than perl when it comes to assigning these values.