Skip Menu |

This queue is for tickets about the Math-BigInt CPAN distribution.

Report information
The Basics
Id: 49569
Status: resolved
Priority: 0/
Queue: Math-BigInt

Owner: Nobody in particular
Requestors: shmuelfomberg [...]

Bug Information
Severity: (no value)
Broken in: 1.89
Fixed in: (no value)

Subject: pack "Q" and BigInt
Download (untitled) / with headers
text/plain 415b
The following line of code: print unpack "H*", pack "Q>", Math::BigInt->new("18446744073709551360"); prints 'ffffffffffffffff' instead of 'ffffffffffffff00' that I expect it to, if use64bitint is defined and uselongdouble is not. If uselongdouble is defined too, that that line works. See the reports at: for many reports. Shmuel.
Download (untitled) / with headers
text/plain 695b
The problem here is that an implicit ->numify() is done on the Math::BigInt object, converting the value 18446744073709551360 into 1.84467440737096e+19, which gives the wrong result: $ perl -MMath::BigInt -wle '$x = Math::BigInt->new("18446744073709551360"); print unpack "H*", pack "Q>", $x->numify()' ffffffffffffffff It works fine if you stringify the Math::BigInt object with "$x" or $x->bstr(): $ perl -MMath::BigInt -wle '$x = Math::BigInt->new("18446744073709551360"); print unpack "H*", pack "Q>", $x->bstr()' ffffffffffffff00 I have tracked down the problem to Math::BigInt::FastCalc->_num(). I'm no good at XS code, so perhaps someone with better XS knowledge than me can fix this?
Download (untitled) / with headers
text/plain 329b
Hi. Do you have such a machine? If you do, I may be able to build custom versions of FastCalc that print debug info, and we may be able to figure out what is happening. I suspect some int/float conversions go wrong in the C level. but first we need a dump of the BigInt object that is created. Can you do that? Thanks, Shmuel.
Download (untitled) / with headers
text/plain 273b
Hi. I just got another bug report that may be related: it means that the same command, gives fffffff7839ad109 on Linux 64 bit, with all the 64-bit flags defined. does it makes any sense? Shmuel.
Download (untitled) / with headers
text/plain 260b
The bug in this ticket's first report is fixed with Math::BigInt::FastCalc version 0.25. Hopefully, this also fixes the most recent report, although I don't understand why the value fffffff7839ad109 shows up. If this bug is still present, please let me know.
Download (untitled) / with headers
text/plain 156b
I think that the bug is still present. here is a automated test report: Shmuel.
Download (untitled) / with headers
text/plain 750b
The report contains no information about which version of Math::BigInt::FastCalc that is being used. I assume therefore that a version < 0.25 is used. I am able to reproduce the bug with Math::BigInt v1.991 and Math::BigInt::FastCalc v0.24: $ perl -MMath::BigInt -wle 'print unpack "H*", pack "Q>", Math::BigInt->new("18446744073709551360");' ffffffffffffffff However, with Math::BigInt v1.991 and Math::BigInt::FastCalc v0.25: $ perl -MMath::BigInt -wle 'print unpack "H*", pack "Q>", Math::BigInt->new("18446744073709551360");' ffffffffffffff00 I suggest you add Math::BigInt::FastCalc v0.25 to your list of prerequisites. If you do, please let me know if that helps.
Download (untitled) / with headers
text/plain 211b
We will get better diagnostics messages if you edit the 05bigint.t test script to utilise the features in Test::More. Please change ok( $ans eq $string, "UBInt64: ...); into is( $ans, $string, "UBInt64: ...);
Download (untitled) / with headers
text/plain 551b
I don't think that it is good idea to start declaring version of sub-sub-modules. In my point of view, it is bug in Math::BigInt if it allow itself to be used with sub-modules hat have bugs in them. my interface is Math::BigInt, and I should not care about how it does its calculation. so, please release a new version of Math::BigInt, with the version of FastCalc bumped up, and my bug in the tests. Then we will look on the CPAN testers reports, see that the new module does not fail in the this test, and then I will require this version. deal?
Download (untitled) / with headers
text/plain 282b
That is indeed a good point. I agree with you. I still hope that you, in the next release, will change ok() to is() in the test scripts. The ok() function shows the actual output vs. the expected output. The more information I get, the easier it is to track down this annoying bug.
Download (untitled) / with headers
text/plain 133b
On Tue Feb 15 15:02:09 2011, pjacklam wrote: Show quoted text
> The ok() function shows (...)
That should have been: "The is() function shows (...)".
I verified that the issue is solved. thanks.
Download (untitled) / with headers
text/plain 112b
On Tue Mar 01 12:19:24 2011, SEMUELF wrote: Show quoted text
> I verified that the issue is solved. > thanks.
That is good news!
Download (untitled) / with headers
text/plain 105b
A specific testcase for this issue is now included in blead, as 02916adf982e17a20465ed6e7008686ec9499a1e.
Please close this ticket.

This service is sponsored and maintained by Best Practical Solutions and runs on infrastructure.

Please report any issues with to