[VOTE] Forbid dynamic calls to scope introspection functions

php.internals

Nikita Popov

10 years ago
Hi internals, The RFC https://wiki.php.net/rfc/forbid_dynamic_scope_introspection is now in voting. The vote closes on 2016-05-24 with a required majority of 2/3. Nikita

Bishop Bettini

10 years ago
> > The RFC > > https://wiki.php.net/rfc/forbid_dynamic_scope_introspection > > is now in voting. The vote closes on 2016-05-24 with a required majority of > 2/3.
I voted no. While I agree these appear to be exotic use cases, my quibble boils down to the assumption these minimally exist in the wild. Several templating systems rely on extract, and func_get_args drives several framework collection classes. I can see userland invoking these inside of array_map (etc) and dynamically. I'd be a Yes if we start with a warning in 7.1 and then error in the next major.

Nikita Popov

10 years ago
On Sun, May 15, 2016 at 10:46 PM, Nikita Popov <nikita.ppv@gmail.com> wrote:
> Hi internals, > > The RFC > > https://wiki.php.net/rfc/forbid_dynamic_scope_introspection > > is now in voting. The vote closes on 2016-05-24 with a required majority > of 2/3. > > Nikita >
Thanks to a comment on Reddit, I realized that the function list in the RFC is missing "assert() with a string argument" as a forbidden function. The reason is that assert() with a string is really just a different way of saying eval() -- so it will inherit the parent symbol table and may modify it. I missed this because the function was also missing from the opcache indirect var access list (remedied in [1]). I hope it's not a problem to add this case to the RFC even though it's already in voting. Nikita [1]: https://github.com/php/php-src/commit/b65b15c6f470cc3397ff7719d92cecc762c803e9

Nikita Popov

10 years ago
On Tue, May 17, 2016 at 4:33 PM, Nikita Popov <nikita.ppv@gmail.com> wrote:
> On Sun, May 15, 2016 at 10:46 PM, Nikita Popov <nikita.ppv@gmail.com> > wrote: > >> Hi internals, >> >> The RFC >> >> https://wiki.php.net/rfc/forbid_dynamic_scope_introspection >> >> is now in voting. The vote closes on 2016-05-24 with a required majority >> of 2/3. >> >> Nikita >> > > Thanks to a comment on Reddit, I realized that the function list in the > RFC is missing "assert() with a string argument" as a forbidden function. > The reason is that assert() with a string is really just a different way of > saying eval() -- so it will inherit the parent symbol table and may modify > it. I missed this because the function was also missing from the opcache > indirect var access list (remedied in [1]). > > I hope it's not a problem to add this case to the RFC even though it's > already in voting. > > Nikita > > [1]: > https://github.com/php/php-src/commit/b65b15c6f470cc3397ff7719d92cecc762c803e9 >
The RFC has been accepted with 39 votes in favor and one against. The implementation has landed in [1]. As mentioned previously, assert() with a string argument (aka eval) is also part of the final implementation. Nikita [1]: https://github.com/php/php-src/commit/91f5940329fede8a26b64e99d4d6d858fe8654cc