Bug #80796 [Fbk->NoF]: decbin errors out on 32-bit PHP installs with "negative" numbres
Edit report at https://bugs.php.net/bug.php?id=80796&edit=1
ID: 80796
Updated by: php-bugs@lists.php.net
Reported by: terrafrost@php.net
Summary: decbin errors out on 32-bit PHP installs with
"negative" numbres
-Status: Feedback
+Status: No Feedback
Type: Bug
Package: Math related
Operating System: Windows 10
PHP Version: 8.0.2
Private report: N
New Comment:
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Re-Opened". Thank you.
Previous Comments:
------------------------------------------------------------------------
[2021-02-26 21:14:37] terrafrost@php.net
Well let me put it another way.
Since bindec() gives float(4294967295) for str_repeat('1', 32) on 32-bit PHP installs it
seems to me that decbin() ought to accept float(4294967295).
A more poignant example: var_dump(bindec(decbin(-1))); gives float(4294967295). It doesn't give
int(-1) - it gives float(4294967295).
I mean, personally, I don't see it as an issue if decbin(-1) and decbin(0xFFFFFFFF) give the
same result (with -1 being encoded in two's complement and the latter being encoded as an
unsigned int). Sure, this means the output of bindec() is ambiguous but ambiguous is better than
inconsistent, which is the situation we're currently in, wherein the only way to get decbin()
to return str_repeat('1', 32) is by giving it a completely different value than what
bindec() would return.
Also, technically, for 32-bit systems, floats are still 64 bits, which means that you can represent
every whole numbers between 0 and (1<<52)-1 without a loss of precision. See IEEE 754.
Just my two cents...
------------------------------------------------------------------------
[2021-02-24 18:44:52] requinix@php.net
It already does allow floats - when they can be converted to integers without loss. Allowing all
floats won't work because larger and larger values have less and less precision in the
least-significant bits, and that means "incorrect" outputs.
------------------------------------------------------------------------
[2021-02-24 16:38:55] terrafrost@php.net
Description:
------------
decbin(float(0xFFFFFFFF)) produces an error on 32-bit PHP 8 installs but decbin(float(0x7FFFFFFF))
doesn't.
On 32-bit installs 0xFFFFFFFF is outside the range of a signed 32-bit integer so it can't be
represented as anything other than a float but still... I wonder if maybe allowing for floats might
not be a bad idea?
This is, in particular, an issue on Raspberry Pi's.
I mean if it's intended behavior that's cool too - just seems like it could be an
oversight.
Test script:
---------------
<?php
echo decbin(floatval(0xFFFFFFFF)) . "\n"; // errors out on PHP 8; works fine on PHP 7.4
echo decbin(floatval(0x7FFFFFFF)) . "\n"; // works fine on PHP 8 and PHP 7.4
Expected result:
----------------
11111111111111111111111111111111
Actual result:
--------------
Fatal error: Uncaught TypeError: decbin(): Argument #1 ($num) must be of type int, float given
------------------------------------------------------------------------
--
Edit this bug report at https://bugs.php.net/bug.php?id=80796&edit=1
Thread (7 messages)