PHP :: Bug #80796 :: decbin errors out on 32-bit PHP installs with "negative" numbres

[2021-02-24 16:38 UTC] 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

[2021-02-24 18:44 UTC] requinix@php.net

-Status: Open +Status: Feedback

[2021-02-24 18:44 UTC] 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-26 21:14 UTC] 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-03-07 04:22 UTC] php-bugs at lists dot php dot net

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.

[2021-03-07 07:32 UTC] requinix@php.net

-Status: No Feedback +Status: Open

[2021-08-13 14:32 UTC] cmb@php.net

-Status: Open +Status: Wont fix -Assigned To: +Assigned To: cmb

[2021-08-13 14:32 UTC] cmb@php.net

Well, decbin() is *one* of the math functions which became
stricter in PHP 8.0, and I think it makes sense, overall. The old
behavior of silently truncating floats[1] could be quite
confusing, and the 64bit behavior for very large numbers was a
real footgun[2].  I get your argument regarding the broken
roundtrip behavior, but I still consider this as a more general
issue, namely that integers silently overflow to floats, what
should better be targeted by introducing big integers[3], or maybe
some other solution, but anyway, that would require the RFC
process[4].

[1] <https://3v4l.org/5TkYu>
[2] <https://3v4l.org/0VvHu>
[3] <https://wiki.php.net/rfc/bigint>
[4] <https://wiki.php.net/rfc/howto>

Patches

Pull Requests

History

	php.net \| support \| documentation \| report a bug \| advanced search \| search howto \| statistics \| random bug \| login
go to bug id or search bugs for


Copyright © 2001-2024 The PHP Group All rights reserved.	Last updated: Tue Apr 23 19:01:31 2024 UTC