Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124337
Date: Wed, 10 Jul 2024 10:28:13 +0100 (BST)
To: Claude Pache <claude.pache@gmail.com>
cc: Larry Garfield <larry@garfieldtech.com>, 
    php internals <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC] Property Hook improvements
In-Reply-To: <8A3C2FDA-60DF-45A1-BA9D-11B6FB6F755C@gmail.com>
Message-ID: <80f69fe5-4409-6c8c-5807-de66edf23ceb@php.net>
References: <fbf45a9a-0385-4c42-a6a0-4f3ee1c8728d@app.fastmail.com> <8A3C2FDA-60DF-45A1-BA9D-11B6FB6F755C@gmail.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-1218124254-1720603693=:3691"
From: derick@php.net (Derick Rethans)

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323329-1218124254-1720603693=:3691
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: QUOTED-PRINTABLE

On Wed, 3 Jul 2024, Claude Pache wrote:

> > Le 1 juil. 2024 =C3=A0 19:02, Larry Garfield <larry@garfieldtech.com> a=
=20
> > =C3=A9crit :
> >=20
> > Hi folks.  As Ilija's been polishing off hooks to get the PR merged,=20
> > we've run into two small revisions that should make life better for=20
> > all involved.  One is a performance improvement that requires a very=20
> > slight error handling behavior change, and the other is enabling=20
> > readonly in selected (but probably all of the relevant)=20
> > circumstances.
> >=20
> > I'd say we expect these to be uncontroversial, but this is PHP. :-) =20
> > So I will instead just note that it's a short RFC and open the=20
> > discussion accordingly.
> >=20
> > https://wiki.php.net/rfc/hook_improvements
>=20
> 1. Removing the guard against recursion is sensible to me, as the sort=20
> of bug it is supposed to prevent is not specific to property=20
> accessors. IMO, a better solution to the issue is to implement a=20
> global upper limit on the call stack size.

That is already done in PHP 8.4, if you end up using too much stack, PHP=20
will now bail out graciously:=20
https://github.com/php/php-src/blob/master/Zend/zend_call_stack.c

> Currently, I am able to generate a call stack of more than 10 millions=20
> items before an OOM error occurs; PHP should have thrown a stack=20
> overflow error long before that.

Why? Most actual function calls are not done on the stack any more. So=20
it is now perfectly okay to have that many nested calls. If you want it=20
to bail out earlier (during testing), then Xdebug will help you.

cheers,
Derick


--=20
https://derickrethans.nl | https://xdebug.org | https://dram.io

Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/suppo=
rt

mastodon: @derickr@phpc.social @xdebug@phpc.social
--8323329-1218124254-1720603693=:3691--