Deprecate and then remove, or just leave it in. "Make it optional forever" just generates more nonportable PHP code. Ick.
On Sun, Feb 5, 2012 at 3:28 PM, Stas Malyshev <smalys...@sugarcrm.com> wrote: > Hi! > > >> Removing this would obviously be an inconvenience for some people, >> but getting your server hacked is also an inconvenience, and hackers >> don't give you nice warnings with file and line number. I like the >> idea of doing _something_ here. Deprecate now and remove later sounds >> fair. > > > Inconvenience is fairly minimal - you can easily rewrite it with > preg_replace_callback, which given we have now anon functions is no more > verbose, much easier to understand and has no security problems whatsoever, > seems to be a win. The problem with /e is not people that do not sanitize, > the problem is that sanitizing properly is not easy and people regularly > mess it up and don't even know it. > Yes, that means that some code will have to be patched - but it can be > easily done, even in backwards-compatible way since preg_replace_callback is > available since forever. And the resulting code will also be faster (though > probably it wouldn't matter :) > > -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ > (408)454-6900 ext. 227 > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
