Edit report at https://bugs.php.net/bug.php?id=69906&edit=1
ID: 69906
Updated by: phpdocbot@php.net
Reported by: ab@php.net
Summary: chr() behavior difference between 32- and 64-bit
bulids
-Status: Re-Opened
+Status: Closed
Type: Documentation Problem
Package: Strings related
Operating System: any
PHP Version: *
Assigned To: cmb
Block user comment: N
Private report: N
New Comment:
Automatic comment on behalf of cmb
Revision: http://git.php.net/?p=doc/en.git;a=commit;h=eaff4ac6338e42ab28f161a95cd7d9e6139891cc
Log: Fix #69906: chr() behavior difference between 32- and 64-bit bulids
Previous Comments:
------------------------------------------------------------------------
[2020-11-04 13:22:17] cmb@php.net
The most relevant issue here is that prior to PHP 7.4.0[1], chr()
did not warn about unsupported input. Any value was silently
accepted and cast to zero unless it could be coerced to int. That
even happend in strict_type code for all non integer values.
[1] <http://git.php.net/?p=php-src.git;a=commit;h=714d9fc358640069bda5540c2b1136a6241c4c94>
------------------------------------------------------------------------
[2015-06-24 12:44:23] ab@php.net
Jan,
yeah, quite a behavior difference can be seen here and there. In most cases it's related to the
implementation of https://wiki.php.net/rfc/zpp_fail_on_overflow
. Additionally, we have an alternative API (aka fast ZPP) which partially replaces the old one where
it makes sense, here also a slight difference can be seen. For instance, you can compare rand(0,
2632627629) on x64/x86 in PHP7 and PHP5. But actually any other functions taking integer arguments.
Hereby one should be aware that on Windows it's once more different again, because PHP7 has
full 64-bit support cross platform - so it's kinda new land for the users yet. But as
mentioned, it's now consistent across platforms. In general, switching to x64 would bring the
most correct results probably.
Thanks.
------------------------------------------------------------------------
[2015-06-24 12:06:02] jan dot slabon at setasign dot com
Anatol,
Do you have some other functions which are also affected by this behavior change?
Thanks!
Jan
------------------------------------------------------------------------
[2015-06-24 09:10:09] ab@php.net
Jan,
ok, doc bug sounds appropriate. Thanks for more extended info.
Actually it's not a local BC, but might be found somewhere else and is a general behavior
change. In PHP5 on 32-bit it would happily allow the internal integer argument to be overflown by
that big integral constant, while in PHP7 it'll be always truncated to zero.
Thanks.
------------------------------------------------------------------------
[2015-06-24 07:06:16] jan dot slabon at setasign dot com
Hi Bob, hi Anatol,
I reported that problem while talking to Anatol about another bug by email. We really had such code
which got broken by this change.
So technically it is a BC break but I'm not sure if we are the only one trapping into that
issue?
We encountered the problem in an Ascii85 encoder which we fixed now by casting to int explicity. So
I don't have a problem with this BC break as we've a fix for it:
$r = 0;
for ($j = 0; $j < 5; ++$j) {
$r = (int)($r * 85 + $chn[$j]);
}
$out .= chr($r >> 24)
. chr($r >> 16)
. chr($r >> 8)
. chr($r);
Anyhow this problem will only arise in special situations and will not be recognized until it
happens (in our case PDF documents that uses an Ascii85 filter - very rare), which may lead people
to think that the code is fine with PHP 7 while it is not...
Here are some os projects/packages which current versions are affected:
https://packagist.org/search/?q=fpdi
https://packagist.org/search/?q=mpdf
https://packagist.org/search/?q=pdfparser
(depends on https://packagist.org/search/?q=tcpdf which seems
to use such structure in its filter class/method, too - which is actually only used by the
pdfparser)
Additionally there are some hundreds packages depending on these packages, too.
If you want to stay with this BC break this have to be documentated.
At our end this would force people to update not only to PHP 7 but to the latest library version. So
I'm fine with this BC break.
Anyhow it could end in some trouble around these packages and users.
Cheers,
Jan
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=69906
--
Edit this bug report at https://bugs.php.net/bug.php?id=69906&edit=1