Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:57746 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 56184 invoked from network); 5 Feb 2012 20:37:57 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 5 Feb 2012 20:37:57 -0000 Authentication-Results: pb1.pair.com header.from=tom@punkave.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=tom@punkave.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain punkave.com designates 209.85.210.170 as permitted sender) X-PHP-List-Original-Sender: tom@punkave.com X-Host-Fingerprint: 209.85.210.170 mail-iy0-f170.google.com Received: from [209.85.210.170] ([209.85.210.170:35007] helo=mail-iy0-f170.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id BB/31-48677-4A8EE2F4 for ; Sun, 05 Feb 2012 15:37:57 -0500 Received: by iakk32 with SMTP id k32so8569420iak.29 for ; Sun, 05 Feb 2012 12:37:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.189.137 with SMTP id gi9mr17828837igc.29.1328474274144; Sun, 05 Feb 2012 12:37:54 -0800 (PST) Received: by 10.231.178.65 with HTTP; Sun, 5 Feb 2012 12:37:54 -0800 (PST) In-Reply-To: <4F2EE658.2010504@sugarcrm.com> References: <4F2EE658.2010504@sugarcrm.com> Date: Sun, 5 Feb 2012 15:37:54 -0500 Message-ID: To: PHP Internals Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [PHP-DEV] [RFC] Deprecate and remove /e modifier from preg_replace From: tom@punkave.com (Tom Boutell) 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 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