php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #68480 unpack unsigned large number becoming negative
Submitted: 2014-11-22 12:07 UTC Modified: 2014-11-25 17:52 UTC
From: ignasimg at gmail dot com Assigned:
Status: Wont fix Package: *General Issues
PHP Version: Irrelevant OS: Irrelevant
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please — but make sure to vote on the bug!
Your email address:
MUST BE VALID
Solve the problem:
49 + 27 = ?
Subscribe to this entry?

 
 [2014-11-22 12:07 UTC] ignasimg at gmail dot com
Description:
------------
According to the documentation page about unpack:
http://php.net/manual/en/function.unpack.php

Caution
[...] If you unpack a large unsigned long and it is of the same size as PHP internally stored values the result will be a negative number even though unsigned unpacking was specified.



My question (beside wtf?) is would it be so hard to specify inside the unpack function that if unsigned was required make it become unsigned? 
I mean... it might sound stupidly ridicoulous but why is there an unsigned format if it acts the same as with signed?

There's even some funny solution on the same page comments:

if ($unpackedVal <0)
{
      $unpackedVal += 4294967296;
}

which is platform dependent and probably inefficient.

But since I have no idea about the inner workings of PHP my question again is would it be so difficult to make it behave properly?


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2014-11-25 17:52 UTC] aharvey@php.net
-Status: Open +Status: Wont fix
 [2014-11-25 17:52 UTC] aharvey@php.net
PHP doesn't have an unsigned integer (or bigint) type, so there's no way to return it as an unsigned integer unless the number gets returned as a float, which obviously risks losing precision. (This is effectively what the "solution" does — on a 32 bit architecture, that addition will cause $unpackedVal to be converted to a float.)

Closing, since this requires a language change (which then requires an RFC, a patch, et cetera).
 [2014-12-01 00:49 UTC] ignasimg at gmail dot com
"so there's no way to return it as an unsigned integer unless the number gets returned as a float" so do it!

The only problem you point out is the possible loss of precission, but afaik loss of precission only occurs with fractional values and values that are much larger than the maximum integer. 

And even if it was the case that some big integer value say X did loss precission when converting to float. This precission would be lost aswell when you do:

$a = X;

because as said php would store it as a float.


Maybe I'm missing something but I really can't understand why it can't return a float type.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sat May 18 13:01:32 2024 UTC