Req #68480 [Opn->Wfx]: unpack unsigned large number becoming negative

Edit report at https://bugs.php.net/bug.php?id=68480&edit=1 ID: 68480 Updated by: aharvey@php.net Reported by: ignasimg at gmail dot com Summary: unpack unsigned large number becoming negative -Status: Open +Status: Wont fix Type: Feature/Change Request Package: *General Issues Operating System: Irrelevant PHP Version: Irrelevant Block user comment: N Private report: N New Comment: 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). Previous Comments: ------------------------------------------------------------------------ [2014-11-22 12:07:57] 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? ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=68480&edit=1