Re: [PHP-DEV] BC breaking changes in PHP 8.1

[Thomas Nunninger]

Hi,

Am 22.09.21 um 15:29 schrieb Matthew Weier O'Phinney:

Here's the issue: while overall, I like the move to resource objects,
introducing them in a MINOR release is hugely problematic.

Previously, you would do constructs such as the following:

 if (! is_resource($resource) || get_resource_type($resource) !==
$someSpecificType) {
 // skip a test or raise an exception
 }

Resource objects, however:

- Return `false` for `is_resource()` checks.
- Raise a warning for `get_resource_type()` checks, and/or report the
resource object class name — which differs from the previous resource names
in all cases.


Would it be helpful if is_resource() raises an error if a resource 
object is provided as argument instead of returning false? (Should that 
be limited to the newly introduced resource objects in 8.1? Would a 
deprecation be enough?)


Of course, existing code would not work with that change. But you should 
be able to spot the error and fix it.


It should be possible to write code that works with PHP < 8.1 and >= 
8.1. Combined with Rowans idea of a Resource base class or interface 
that might even be easier?


(I assume it's of no additional help to change get_resource_type() to 
accept resource objects and return the same result as the former, 
corresponding resource type.)


Regards
Thomas

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] PHP 7.4.24 Released!

[Derick Rethans]

The PHP development team announces the immediate availability of PHP
7.4.24. This is a security and bug fix release.

All PHP 7.4 users are encouraged to upgrade to this version.

For source downloads of PHP 7.4.24 please visit our downloads page.
Windows binaries can be found on the PHP for Windows site. The list of
changes is recorded in the ChangeLog.

A migration guide is available in the PHP Manual. Please consult it for the
detailed list of new features and backward incompatible changes.

Release Announcement: 
Downloads:
Windows downloads:
Changelog:
Migration guide:  

Many thanks to all the contributors and supporters!

Derick Rethans

P.S. Below is the verification information for the downloads, which is
also available on
.


php-7.4.24.tar.gz
SHA256 hash: 8cc1758cf7ff45428c17641b1be84cd917a2909ba40c770f06a814d8b7f36333
PGP signature:
-BEGIN PGP SIGNATURE-

iQIzBAABCgAdFiEEWlKIB4H3VWCL+BX8kQ3rRvU+oxIFAmFJwSsACgkQkQ3rRvU+
oxKmJw//fdBeMvNefJ/Hdb1x/rYDXlB+XhJa2xUu7T56xgE+GcJ/mDNwmHPD/Cwi
cZ9VTLXoqE+F8U1p9q7+ISDOopIHMp4Nw2B08cX6uwaoR9QkLQR1PuboVRCmkgFk
C7DmM7QpjC8+jIUWsK3KSgxvHJlg0WIh02NbYBtxxQlQyYobLeQa9dgRLPf7iCtM
aVQ3/Qk6gxoV5yKIHH+fh1prHnf5idukMX4vWWOMWfckn0Uvkcfu1E+gNt9ZghTB
2miYWhAEdcBTzbNqohSj4iART1RGpS6Wg5gmuhpAIMOhSHmH9zSBNZwx/dyhNXJR
3r4QSUDgMAgwJK4IFvpbl21yMFQuCYGEaRM+UkbgJb2Tl3Lp5CQICdnQg0is3NpU
n6IdEfWQArhETfUplIdsJeOHUJuw+QA0iN26GBEL70inIIl1F4z1TNWQhOg+rRAZ
k5tF/Ez06vL50jg8/sPHKAHPcx9j8P7ngcGOboe0Wh/Gw8YPwELhDEiGuVKYfgoD
YQGf0fk/Z5E/A3ahEOy05nSPmzTwON/TUbPeF1NXxknQ7KqR0IW19RjfF5v0KzCY
C4kMrrbXjid9BP1tz2pR94U4xbXpUAgAxVUjGs6LdrDAIsJf9BtFsErpoUIdwYdb
VOon3sg1tt0J01PfVKZdPOlmx8VnM3XUJn6WOr5rZNL9b6qmzFA=
=mx6l
-END PGP SIGNATURE-

php-7.4.24.tar.bz2
SHA256 hash: f50e32b788864349041f19e31dcc65b1fcc65bc19122918f607526432edf2f32
PGP signature:
-BEGIN PGP SIGNATURE-

iQIzBAABCgAdFiEEWlKIB4H3VWCL+BX8kQ3rRvU+oxIFAmFJwS4ACgkQkQ3rRvU+
oxJ66A//cBxG/IS2UbYMqPa0fgXp/60U0et5Ig9Caz9DelL520FvgfFBkuODzYSP
uSlgv15xhGxDW6qR2S1sHM/nvuPa59gPXRfz5vqBOEUYDYVbt0Mzovn2UNDstlka
PEC1gM5DalvF/YskroWBVTpo8lAsdnRuCTdN4LRaPMpDFAb6vKI8Kc9KyRr0gLci
Bo6xNcOQX9DTUJvEbRGU4lDFkXi80bMDR1wOvthTlZ/G6D2+enZGOnfBynORn8zU
5y8q/x0EVR1wNj1g7RrXb4XEdGhlFg6FubRKKYurqqCy/9FXj4uxeS2iTjsryoLF
am0buTFQcY1zowB9pu88vxqHPK8u6I2erXnfBCps0xdfeZDIMz2idNrUuBXGslBL
PUNgfkNPTYfTl7Mr9kytI9kWJPbG5YEj8W63a1uUACG3YjgSFS71N9Hx8svgdtg4
lPG1UX1IHK6pjiA/OWUbXUSjmJMS28eiaDXKSkobSNcaCn+fmAmjXLz6BDlywV0T
9E58BBT6T+N0HmMDF5i5QSrDWEgoKsk2lI8gCPf7i6UrIWlvUNx0hMp5mvGnv8+Z
yc542Kml8lv82wyw7ooNvvWRPaNnzW8rpAQWQ6zlxH2kVESE1Rs92b9L02gGcTSZ
532bVI/hJLvy5P9q9Qbz1v75yUwhQM76xwcLonwGIMTZXsh6Oh4=
=BpzR
-END PGP SIGNATURE-

php-7.4.24.tar.xz
SHA256 hash: ff7658ee2f6d8af05b48c21146af5f502e121def4e76e862df5ec9fa06e98734
PGP signature:
-BEGIN PGP SIGNATURE-

iQIzBAABCgAdFiEEWlKIB4H3VWCL+BX8kQ3rRvU+oxIFAmFJwS4ACgkQkQ3rRvU+
oxI4+xAAumxIH0RjSQl5iIlldvOSsUkAXa8Ag0BOp3WHVeEjh4b9Z6URsV7XDDRR
Nopbk6hhGW1QTYFLtUrmEn9bL70GYia9B2tG49SywDT0Ie3+tMOqjMjTjvj3rOL5
ByGrn5dNwKtTdDp2PsykrSwuVu6d5rbbHiJ0wn/AGcR5dPotYi7yoGnmuah1jaGD
YpetDbtGcua+lteoCVNkCS3IMU83NEZraz70a4xfy7U6gMMsrNNzeE2yt/1RwTVY
/dzN0BUZexLbE1xKjjY6+PUtQNXnQttWIC8vg/iSyfRJmVXjftxu02Sa2UQg7fFn
wWxmPCyBrzJNSvXchsKml6e6H0h3BFMG+lD+jJHEcb0Fi/vKLdKYpRgGq8SnIN4E
4mxhSk326eqF1Zo1eUdFjbrvk4khVccGYXSCotpqMJmH6lWrLM1qenreCN+PSBl4
KvCi3WLZADDY8DLWNCkQqoSSdD/v1mkreKWiFVnS66oByQN6lHzWK7//K1cFmXNa
01Q0Ri0gtQqKzwm+TXLXkG+BAdV1Pq9Ed5DSKXsrjiLJUHfjFyZuboUiU9uW+7+m
uBRjSILpyYoCvHFz8J9NBOc2b7V2MCug50RxjtU8gsTSqjtsbeM/ezLSepv9EL5w
au2i12QdHSa/5a59O+M2xDp8FoS11Yy9z1ZEL8k7PU/zatSBJN8=
=q2Pz
-END PGP SIGNATURE-


-- 
PHP 7.4 Release Manager
Host of PHP Internals News: https://phpinternals.news
Like Xdebug? Consider supporting me: https://xdebug.org/support
https://derickrethans.nl | https://xdebug.org | https://dram.io
twitter: @derickr and @xdebug

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] BC breaking changes in PHP 8.1

[Rowan Tommins]

On 23/09/2021 17:52, Nikita Popov wrote:

If we dropped
all non-deprecation changes from PHP 8.1, the upgrade would be a bit
easier, but not by much. This is not where the main cost is.



Be that as it may, the question remains whether *the particular case of 
is_resource() and get_resource_type()* could be made easier.


Was the option of having a "Resource" base class or interface ever 
discussed? If it had a method called something like 
"getResourceTypeString()" then get_resource_type() could do (the 
internal equivalent of):


if ( is_resource($arg) ) {
   // current logic
}
elseif ( is_object($arg) && $arg instanceOf Resource ) {
    return $arg->getResourceTypeString();
}


I suspect as 8.0 and then 8.1 gain adoption, there is going to be a lot 
of confusion around the resource -> object change. Most users probably 
don't really know what a "resource", they just know the boilerplate to use.


Regards,

--
Rowan Tommins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] BC breaking changes in PHP 8.1

[Nikita Popov]

On Wed, Sep 22, 2021 at 3:30 PM Matthew Weier O'Phinney <
mweierophin...@gmail.com> wrote:

> Yesterday, I opened an issue regarding a change in the pgsql extension (
> https://bugs.php.net/bug.php?id=81464).
>
> PHP 8.0 introduced the concept of "resource objects". Where previously we
> would have resources, and use `get_resource_type()` when we needed to
> differentiate various resources, resource objects give us immutable objects
> instead that allow us to type hint. Personally, I think this is wonderful!
>
> The rollout for 8.0 was incomplete, however, and only touched on something
> like 4-6 different resource types. Still, a good start.
>
> With PHP 8.1, we're seeing the addition of more of these, and it was
> encountering one of those changes that prompted the bug I previously linked
> to.
>
> Here's the issue: while overall, I like the move to resource objects,
> introducing them in a MINOR release is hugely problematic.
>
> Previously, you would do constructs such as the following:
>
> if (! is_resource($resource) || get_resource_type($resource) !==
> $someSpecificType) {
> // skip a test or raise an exception
> }
>
> Resource objects, however:
>
> - Return `false` for `is_resource()` checks.
> - Raise a warning for `get_resource_type()` checks, and/or report the
> resource object class name — which differs from the previous resource names
> in all cases.
>
> This means conditionals like the above BREAK. As a concrete example, I did
> PHP 8.1 updates for laminas-db last week, and assumed our postgres
> integration tests were running when we finally had all tests passing
> successfully. However, what was really happening was that our test suite
> was testing with `is_resource()` and skipping tests if resources were not
> present. We shipped with broken pgsql support as a result, and it wasn't
> until test suites in other components started failing that we were able to
> identify the issue.
>
> Further, the "fix" so that the code would work on both 8.1 AND versions
> prior to 8.1 meant complicating the conditional, adding a `! $resource
> instanceof \PgSql\Connection` into the mix. The code gets unwieldy very
> quickly, and having to do this to support a new minor version was
> irritating.
>
> When I opened the aforementioned bug report, it was immediately closed as
> "not an issue" with the explanation that it was "documented in UPGRADING".
>
> This is not an acceptable explanation.
>
> - There was no RFC related to 8.1 indicating these changes were happening.
> (In fact, there was no RFC for resource objects in the first place — which
> is concerning considering the BC implications!)
> - In semantic versioning, existing APIs MUST NOT change in a new minor
> version, only in new major versions.
>
> Reading the UPGRADING guide, there's a HUGE section of backwards
> incompatible changes for 8.1 — THIRTY-FOUR of them. Nested in these are
> notes of around a half-dozen extensions that once produced resources now
> producing resource objects.
>
> The pace of change in PHP is already breathtaking when you consider large
> projects (both OSS and in userland); keeping up with new features is in and
> of itself quite a challenge. Introducing BC breaks in minor versions makes
> things harder for everyone, as now you have to figure out not only if
> there's new features you want to adopt, but whether or not there are
> changes that will actively break your existing code. I strongly feel that
> anything in the backwards incompatible section of the UPGRADING guide
> should be deferred to 9.0, when people actually expect things to change.


I believe the changes in PHP 8.1 with the highest migration burden for
open-source libraries are the additional of tentative return types (aka
"put #[ReturnTypeWillChange] everywhere") and deprecation of null arguments
to internal functions, followed by the float to int precision-loss
deprecation and, depending on project, the Serializable deprecation.

What all of these have in common, is that they are all semver compliant
changes, because they "only" introduce deprecations. Deprecations are
explicitly not considered backwards-compatibility breaks.

Now, there are two problems with this picture: The first one is that
deprecations often get promoted to exceptions by generic error handlers. I
believe that this continues to be the default behavior of PHPUnit for
example. This means that in practice, deprecations do break code, even
though they are intended not to.

The second one is that this does not really hold up for open-source
libraries. At the application layer, you can suppress all deprecations, and
call it a day. At the library layer, the usual perception is that if your
library throws deprecation warnings, it's not compatible with the given
version of PHP. Taken in conjunction with deprecation to exception
promotion (in test suites if nothing else) there is some truth to that
perception.

While deprecations are intended as a backwards-compatible 

[PHP-DEV] PHP 8.0.11 Released

[Sara Golemon]

The PHP development team announces the immediate availability of PHP
8.0.11. This is a security release fixing CVE-2021-21706.

For source downloads of PHP 8.0.11 please visit our downloads page:
https://www.php.net/downloads
Windows source and binaries can be found at https://windows.php.net/download
The list of changes is recorded in the ChangeLog:
https://www.php.net/ChangeLog-8.php

Many thanks to all the contributors and supporters!
Sara Golemon and Gabriel Caruso

Release Manifest here and below:
https://gist.github.com/sgolemon/65bc563ad57d16069eaa7ab76b8f3046

php-8.0.11.tar.gz
SHA256 hash:
c6a461f57b4bcb46cd4dec443253b1e2e8e981466f1280093322b7864afe8be7
PGP signature:
-BEGIN PGP SIGNATURE-

iQJEBAABCgAuFiEEFyn4OTjaROJ7oPTT29s5dHDRIXIFAmFKEfsQHHBvbGxpdGFA
cGhwLm5ldAAKCRDb2zl0cNEhcjAND/4jpUJn5UbASCnzHlR/VUVVwt0Jg07Y5ZeM
Xt2xvxA5gFankCUa0RYJlmzd1OmNSLlOfVWTwDBvURCwjjHa9asuc3kxSAeXNeGC
7bBdygIDf57rJyN8bcNXSAK/Ld7UqXdF2MqlgbpTfNH76XtBqqN4WQwVdxGXDEq4
yhv7DcPG8d6CXF8byAs2GWP0whrGBiZQjH9Xbxn4AuWLEducivuffVr7PFtn8YVS
MXxrko84MlWn9eYo1b3L42eWuu3HRiay9BfRKgO41CQJdPxoFHrwo7IS8ePuFbGK
xV7+lSa5sCXU0Fy08vY0F/REc+ISP3Zf3kbcWNQttMsgbrT2PBHDzMXhQCGRj0tg
YA2CoX3nrcrnLxV8ELGavv3Oh3YTiBUmkfCfJCme/GojpVmANQO0qd7TOcHjXBJe
Ntp+qE6NYA8IphvRDJHLPlccFKSU6yThen1jwVHA3RZ6baWBSgVXoXssDE7Q5kt/
bjMPn5opoOZw2gYsylAp6BGpMAxsItEPRoP/UcZ1pT6IcCc3HXSmuRVlSjPqzPLH
2lHQFu0PVH3u29zngoYX8SNY4mWMZRPAyS+wkMTButMhaUSm3rFCZnZ9MFMzjRB+
zHrlYLnyZzdlj5etypv1PCcdIMMkeeM8akg+fzLQVnH+GJQITij2+WksZvizK/Hl
bmFXTRx8hQ==
=ZVf0
-END PGP SIGNATURE-

php-8.0.11.tar.bz2
SHA256 hash:
70ed874285e4010c1e2e8937bfb56b13b9ed1b3789dcaf274b793b00c1f4403a
PGP signature:
-BEGIN PGP SIGNATURE-

iQJEBAABCgAuFiEEFyn4OTjaROJ7oPTT29s5dHDRIXIFAmFKEf4QHHBvbGxpdGFA
cGhwLm5ldAAKCRDb2zl0cNEhctXAD/9HFrnYdkUBYo2vD/EjpMzsN+9gPRGMb5YT
e8GOoh6MhVAT9kSS5EdNRfQeaPnL+do2nSlZKKwxEU/VS88YJPa9eD/w9ceuLVs5
ev4fCN5TcYMJoMLBUQKJvYcOWCyJXHB6lKOo7zPnOukdtpSyNMj0EhyZY0UwlSIO
wydbXYmKtcxcHZvNh2V6HWZecUeEMu5cFRFzr96G5d8POo0LpW4YOOp88acd7aTN
qXkRF2BTQha5Jnl6COBDnk4YFbMevsnOAS395CUTxEe6yjODha0kgNHXzqoaPX13
qmILPxX56Aq3II+Gmg5TOwsskz4DZkgd/U+g967LjyqHlNMBVtKLUo5dp98hY+6y
t7g2WA8kPr3I0FJ/zIvwq8Zs+NoZUUs56iJoP0ERuTE6M/92hbyY/dT2QlT8v5z7
m9fISPYm2D7qENdP5xVaVBJjFLiIDhWaWW2doEMyzwYkq/kgX2Ni61eTP9f55iRR
DDtacdLvuE35LFdTSQ1N8TQgf8e3Q1SANe+nDnhOGkZoR/qW4oyMR30PWNvcJtFF
1RgMoWb/PwrQvQXoOVz6ofjkf+7LfMN1CMP8xIjPJ+cFOh8fr+1KHLzl3mLqkWy8
vKfVXhNVFn6sZz4C8xwVp6m3iGHa25Dm/jOLcjNBj781AFQrHT7AdNxdRJaoUEVd
2HppVL5QCA==
=Ik7I
-END PGP SIGNATURE-

php-8.0.11.tar.xz
SHA256 hash:
e3e5f764ae57b31eb65244a45512f0b22d7bef05f2052b23989c053901552e16
PGP signature:
-BEGIN PGP SIGNATURE-

iQJEBAABCgAuFiEEFyn4OTjaROJ7oPTT29s5dHDRIXIFAmFKEf8QHHBvbGxpdGFA
cGhwLm5ldAAKCRDb2zl0cNEhcnqsD/4wSJ/Td0grw9x94Q+rwceRyeo49H/l1t/f
UYt+a6F+EvM/ZxNKGe8gGBsDW4C2J0zBA53GLKNMG/m6tMhBQF3qY4aRJrx/lS6a
VT2SOpfPTiezG31FIkZsx1i4ISLdRpHJfAGKgHWtDlb6m6CJQSGLaIShYwjWVZ2W
M3Bg5ijjGqVIPYUd5LzJX2tqtq48HA8PiAbFMb1OPcwu/1L8rssHklgBcBn2+bc+
ecYt3nhqQyboCfuUuwTofiM7z8tLp8RipMmw2o/oDPVgenYGiQGrcNKOLkxqvblz
pNAv30EhmHqmncoGivoW9qmBSlef6Jafzvy1U4Nmnwc/1r25D47PwNw9S8DTlDjX
nYLAIudAK17fo+fnhBB0S5E7qj7mBfslKDOKACDaGUF0Ynufuy61YC/wbfKphriw
hMq2XqfYRSUvHYoN/upJr4cB4xPzj71odshAgOdSJdT6uTbtIM+MnF1JxeE2Dzz9
RCUB8jhNBBukR0L3sO1Rq5HBMEQgQntZC7KW7CRjW3lwQGuKCPzlxCzvZlinie9Q
LOEJWnyfq+XerAXjdgBmH133nWyLsRQbGQx9szWTctu59YBHQUEwRw9mIcVtjv4Q
cXmMitzvFH+Gsr/mxfQ2nn5qXmd1YQWJZFvfoNUWrYEhknZH80iq4LoOiMpKwsNd
IEVfwu7kTQ==
=DMzd
-END PGP SIGNATURE-

Re: [PHP-DEV] run-tests SKIPIF caching can be problematic for third-party extensions

[Nikita Popov]

On Thu, Sep 23, 2021 at 4:10 PM Nikita Popov  wrote:

> On Wed, Sep 15, 2021 at 7:23 PM Jeremy Mikola  wrote:
>
>> I just discovered that run-tests.php was changed to cache SKIPIF
>> evaluation
>> since 8.1.0beta3[1]. I believe ext-mongodb ran into the same issue as
>> mysqli[2], as we use SKIPIF to check that database contents are clean
>> going
>> into a test. The present solution in core is to check SKIPIF output for
>> "nocache" [3,4] and allow individual tests to opt out of caching; however,
>> I'm worried that won't be portable for third-party extensions, where we
>> test with run-tests.php for each version of PHP that we support.
>>
>> Is there still time to consider an alternative solution? If "nocache"
>> needs
>> to remain in place for mysqli, perhaps 8.1.0's run-tests.php can be
>> enhanced to consult an environment variable (for maximum BC and playing
>> nice with `make test`) that disables caching entirely.
>>
>
> I'm not sure I understand the setup you're using. The "nocache" tag that
> mysqli uses covers the situation where part of the test setup is done in
> the SKIPIF section -- because checking whether the test should be skipped
> requires doing the same setup as the actual test. If the test does get
> skipped, it's still fine to cache that.
>
> Now, it sounds like your situation is different from that, and you
> actually have SKIPIF sections where first one test should be skipped, but
> then a later test with identical SKIPIF shouldn't be skipped. Is that
> correct? What changes between the time these two tests run?
>

Independently of that question (which is about whether "nocache" is
sufficient if we ignore cross-version compatibility issue) I do agree that
an option to disable the skip cache entirely would make sense. Would
https://github.com/php/php-src/pull/7510 work for you?

Regards,
Nikita

Re: [PHP-DEV] run-tests SKIPIF caching can be problematic for third-party extensions

[Nikita Popov]

On Wed, Sep 15, 2021 at 7:23 PM Jeremy Mikola  wrote:

> I just discovered that run-tests.php was changed to cache SKIPIF evaluation
> since 8.1.0beta3[1]. I believe ext-mongodb ran into the same issue as
> mysqli[2], as we use SKIPIF to check that database contents are clean going
> into a test. The present solution in core is to check SKIPIF output for
> "nocache" [3,4] and allow individual tests to opt out of caching; however,
> I'm worried that won't be portable for third-party extensions, where we
> test with run-tests.php for each version of PHP that we support.
>
> Is there still time to consider an alternative solution? If "nocache" needs
> to remain in place for mysqli, perhaps 8.1.0's run-tests.php can be
> enhanced to consult an environment variable (for maximum BC and playing
> nice with `make test`) that disables caching entirely.
>

I'm not sure I understand the setup you're using. The "nocache" tag that
mysqli uses covers the situation where part of the test setup is done in
the SKIPIF section -- because checking whether the test should be skipped
requires doing the same setup as the actual test. If the test does get
skipped, it's still fine to cache that.

Now, it sounds like your situation is different from that, and you actually
have SKIPIF sections where first one test should be skipped, but then a
later test with identical SKIPIF shouldn't be skipped. Is that correct?
What changes between the time these two tests run?

Regards,
Nikita

[PHP-DEV] PHP 7.3.31 Released!

[Christoph M. Becker]

The PHP development team announces the immediate availability of PHP
7.3.31.  This is a security release fixing CVE-2021-21706.

All PHP 7.3 users are encouraged to upgrade to this version.

For source downloads of PHP 7.3.31 please visit our downloads page.
Windows binaries can be found on the PHP for Windows site.
The list of changes is recorded in the ChangeLog.


Release Announcement: 
Downloads:
Windows downloads:
Changelog:

Many thanks to all the contributors and supporters!


Stanislav Malyshev, Christoph M. Becker


php-7.3.31.tar.bz2
SHA256 hash:
6951f78524684f439186fe039ab14fb2459cea8f47ac829a159724a283f7f32b
PGP signature:
-BEGIN PGP SIGNATURE-

iQJABAABCAAqFiEEy69p8XOg/qS1N/Rw1myVkxGLzLYFAmFJs0IMHGNtYkBwaHAu
bmV0AAoJENZslZMRi8y2ih4QAIDqRC9jSQQIfV+YmYgV8eApEe8l6VbMvR4BGFZn
lJAhr/Crz6vnWmEbMT8rDI8dNplWvd1mGr48MO5+QaZbSVvtLQz+Sew4PkcPPztn
ITFr7bCT/VGqtxQRCYGcp3UU5d5J/A/n1gW7aaufFeLsHPfq/5NATotmDVFZlAy4
gmJXPlWZxzXz33abgOYZAc2o9TctLYhUtGAw+RxusU7w3uVlTp7NcJGphhTrDXR4
gJZRLo7iP+ZfEZme2moFLpM67MmnJ9lpb73HJsgxPI7aeAi7nZV6Vu0n559WG1xn
guL0Yr8/jjjF8sUFALP1Pal4xbed9mq61rKsS6eueR0iDPhD6HeiCtEzwQx4E6Fj
F2tNK1jkc3YlQbbOUFcxpYTWR+ZYBIX7MEM6+XLAiLtTHF4NTQhIfC+wssN/qg2T
JRlNJnuwhnJqG+kNyNBSdZC3fhIJc75iGgATJA2/HPE0XaAy8leOVpF5SPn4KuVk
xwE/iPZ72b29Ts8fEUL6RGfURuqp7kijHMuoSw++BjV83iETk9kHhJuIfj+sm3vb
/CcCmiaV/DRlmYpTNkcC/gMiWpcfagl79uZ4KeCQt6AednZAFK70Er+Fyfl7avxd
lMqgVNTPfBOFeO6DHK24kxraDdwKS6us8pxqc/WqNQbB7S0zZ8QhA304LHY27G3/
74OG
=Q6B/
-END PGP SIGNATURE-


php-7.3.31.tar.gz
SHA256 hash:
57ca37b08d3eed4cadc3976e78b0f51d0305bb6e60333f6e8c76e8aee07c3f0f
PGP signature:
-BEGIN PGP SIGNATURE-

iQJABAABCAAqFiEEy69p8XOg/qS1N/Rw1myVkxGLzLYFAmFJs0MMHGNtYkBwaHAu
bmV0AAoJENZslZMRi8y2AFIQAJel7yJqTC/whixm/rNMBVbcDsIGJiDAyOfDVxFz
gYUGvSp/pz2jlqrzGQorH8Wxl+pv4pduRS2B6hl/geHR26ReZqRDIQmzHITuLHZ2
dJHgdeeLS+rMyVOj6NX+Uh5sZR9xHrB0cxOrCoSmxwyyR6UjTW+4ve7rK4BfzSuB
vlJ/ivAWLlgJKXCyKMP9O+j01cqGrpmiHDMcIlI9oiDtrFJllurEyuNG7tIbv1mq
KquCdW4ACB3UylNInFKh/nM/JYB/9VbZqYCtReoja5vISS1nNpgX7B6yadjRZ+CO
rcwPzXlIUyNmF3fWP8AVgMkaVCrmsr/TyF8pIRoIWpdO6HYFKOuWRm1RxwEq8ffc
/NCkIWF6isE2kg35U8X42oW0QbXgkz0lQe26Peswzp3sEKogolDzijNHDJ1Ct3DF
Z9OjQTxnTySKd27chcXd+mFz2DbUmFgb+yV9hZSLkdan5Tr982Fb+1X+tmfFUTru
CiqiQm1AfxL6b2pRkYIBPr0btlHEfizvE12A5lkzZKQFiKaNBM56yvdTCmvm+M4s
AvgNezGHXz8LAY43VXSw7Ks4Rerd9ET+9ZTgJ1XUzRHaB8lb4fWwBa+QwGtlPUCN
cpU0WVQ3nljjly055H+ngapcDkgON0ZfjpVOwTUrF4cR3UXiXSuiE5Kb6sv7+IO6
h7F2
=6zif
-END PGP SIGNATURE-


php-7.3.31.tar.xz
SHA256 hash:
d1aa8f44595d01ac061ff340354d95e146d6152f70e799b44d6b8654fb45cbcc
PGP signature:
-BEGIN PGP SIGNATURE-

iQJABAABCAAqFiEEy69p8XOg/qS1N/Rw1myVkxGLzLYFAmFJs0MMHGNtYkBwaHAu
bmV0AAoJENZslZMRi8y2BAkP/i7YLeyoWHUI1AUEmsRGiVizlbAlm4yR+3XIaYSe
QizRioQHl2nWx9cQnaJiq49UpZS1XXaN6L7MrL8/jMJm4H4Ypi4RRVXGn+UuF43k
KyP7WFa+1bmeRuP2FWilh7xEaSVHQ6mYzT5VM+p5EF7oZFXJCGJ4qDiPwpgIFFr5
9MTeMA8juXWIf0Xo59xmELFXXNxHOHnpgm1Hn3JT+xpkf5Laq966Nh38OLrTJP/w
AOy/ELrFc/OHg+G21ygn1z4H+bDCtP4r4iCAsX1ROCs7Kz4bPpWZfVQWJYLl6igO
SWdMkIHD6uvcqZiPJIMZDPTh/gfmILc1DpX+tWMQ2DJwy25SKoVMH+YX/zI9qnMc
8QJqLqaIVSGzoBaEzoRwI/06Ctrh9FUUPFRmWL9lip42GtidjEEPMVdC+/9fFLX6
PMFdATJFGhwoba7YmIfCfGmdKeGtkcjBGlK241+TqVX7efEu70x4B5Ulegb3u2o3
0Jsxn/fzUhoI6DP6pY486F3Z11yfHjLLj94wxy/OQ5dFK4TNWLeiubQ5rN8lZr+d
9ULIJ+WHW0VPGY5rk0YmTKlo07Ps9zuh/Kue+QwYgOkNXLdptpAqOmiW44G6tMTg
2VDlA3OSqqrlVElRdq8WtYNMe/YEn3kQkOLW5U6sNKuq2OgrUkbq0oMhVA87PXZL
iBOi
=byUN
-END PGP SIGNATURE-

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Locale-independent case conversion

[Tim Starling]

On 23/9/21 4:53 pm, Pierre Joye wrote:
> I wonder if either JIT could be used for the intrinsics support,
> adding neon, sse[2-4.2] or avc256/512 (the latter would basically
> allow most common strings to be converted in one go.
> 
> If not, maybe split implementation however runtime cpu support would
> be better. Many distributions built with SSE2 flags but are actually
> ran on much recent CPUs, same for ARM (ie. graviton/neon f.e.).
> Thoughts?

SSE2 is already scary-fast. I benchmarked the SSE2 tolower code on my
laptop: it was chewing through strings at 18 GiB/s, i.e. 50ps per
byte. This was a benchmark written in C -- you would have a lot of
trouble making a PHP tight loop in which SSE2 case conversion is the
slow part.

-- Tim Starling

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Locale-independent case conversion

[Pierre Joye]

Hi Tim,

On Thu, Sep 23, 2021 at 1:32 PM Tim Starling  wrote:
>
> Please consider my RFC for locale-independent case conversion.
>
> https://wiki.php.net/rfc/strtolower-ascii

very good one, thanks :)


> https://github.com/php/php-src/pull/7506

> The RFC and associated PR ended up going some way beyond the original
> scope, because for consistency, it's best if everything has the same
> concept of case folding. I saw this as an opportunity to clean up a
> common kind of locale-dependence in PHP which was previously inconsistent.

Good patch, I am commenting here as other or more discussions may be
better here.

I wonder if either JIT could be used for the intrinsics support,
adding neon, sse[2-4.2] or avc256/512 (the latter would basically
allow most common strings to be converted in one go.

If not, maybe split implementation however runtime cpu support would
be better. Many distributions built with SSE2 flags but are actually
ran on much recent CPUs, same for ARM (ie. graviton/neon f.e.).
Thoughts?

Maybe Dmitry has a better idea :)

Best,
-- 
Pierre

@pierrejoye | http://www.libgd.org

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] [RFC] Locale-independent case conversion

[Tim Starling]

Please consider my RFC for locale-independent case conversion.

https://wiki.php.net/rfc/strtolower-ascii
https://github.com/php/php-src/pull/7506

The RFC and associated PR ended up going some way beyond the original
scope, because for consistency, it's best if everything has the same
concept of case folding. I saw this as an opportunity to clean up a
common kind of locale-dependence in PHP which was previously inconsistent.

So not only will strtolower() and strtoupper() become
locale-independent, converting only ASCII, but also stristr, stripos,
strripos, lcfirst, ucfirst, ucwords, str_ireplace, the array sorting
functions with SORT_FLAG_CASE, and array_change_key_case.

Also, I changed a number of internal functions to use ASCII case
folding, giving rise to a range of effects in callers throughout the
core tree. The effects are all documented in the RFC.

I am proposing that locale-sensitive case conversion be provided with
the new names ctype_tolower() and ctype_toupper(). Those names might
seem odd at first glance, but they are wrappers for functions in
ctype.h and work in a very similar way to the rest of the ctype extension.

-- Tim Starling

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php