php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #80796 decbin errors out on 32-bit PHP installs with "negative" numbres
Submitted: 2021-02-24 16:38 UTC Modified: 2021-08-13 14:32 UTC
Votes:3
Avg. Score:4.0 ± 0.8
Reproduced:3 of 3 (100.0%)
Same Version:3 (100.0%)
Same OS:1 (33.3%)
From: terrafrost@php.net Assigned: cmb (profile)
Status: Wont fix Package: Math related
PHP Version: 8.0.2 OS: Windows 10
Private report: No CVE-ID: None
View Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: terrafrost@php.net
New email:
PHP Version: OS:

 

 [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

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [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>
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Fri Oct 24 14:00:01 2025 UTC