Hi Derick On Wed, Jul 10, 2024 at 11:32 AM Derick Rethans <der...@php.net> wrote: > > On Mon, 1 Jul 2024, Larry Garfield wrote: > > > > > https://wiki.php.net/rfc/hook_improvements > > 1. Remove the proactive guard against recursive backing value access > > "which would eventually trigger a stack overflow" > > Would it though? PHP 8.4 has an actual protection against this now, > instead of getting the white-screen-of-death. > > Not that it matters much, but it's probably good to be precise in the > language.
Yes, this excerpt is referring to the PHP stack overflow detection, which will throw an exception rather than segfault. That is, on all the architectures that already support stack overflow detection. We're just reusing the same mechanism already used for normal function calls. --- Hi Claude > 1. Removing the guard against recursion is sensible to me, as the sort of bug > it is supposed to prevent is not specific to property accessors. IMO, a > better solution to the issue is to implement a global upper limit on the call > stack size. Currently, I am able to generate a call stack of more than 10 > millions items before an OOM error occurs; PHP should have thrown a stack > overflow error long before that. But this is entirely orthogonal to property > hooks. PHP allows using recursion for algorithms on arbitrarily large data because function calls do not cause the C stack to grow. Limiting the PHP stack size would thus require these algorithms to be rewritten to iterative ones, which can make them more complicated. What we could do is check for stack size on OOM and indicate that the OOM was most likely caused by infinite recursion. Anyway, This does not really apply to hooks, because it will (usually) cause VM reentry for recursion, growing the stack size and thus triggering the "fast" stack overflow detection error. Ilija
