Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:22194 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 62849 invoked by uid 1010); 7 Mar 2006 14:16:27 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 62834 invoked from network); 7 Mar 2006 14:16:27 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 7 Mar 2006 14:16:27 -0000 X-Host-Fingerprint: 217.79.190.163 r163.red.fastwebserver.de Received: from ([217.79.190.163:26874] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.0 beta r(6323M)) with SMTP id 7F/CA-22029-BB59D044 for ; Tue, 07 Mar 2006 09:16:27 -0500 To: internals@lists.php.net,Derick Rethans Date: Tue, 7 Mar 2006 15:16:27 +0100 Message-ID: <20060307151627.67579a91@localhost.localdomain> In-Reply-To: References: <20060307042941.1c7d06c1@localhost.localdomain> Reply-To: Zeev Suraski X-Newsreader: Sylpheed-Claws 1.9.14 (GTK+ 2.8.6; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Posted-By: 217.79.190.163 Subject: Re: [PHP-DEV] Adieu a la magie (remove magic_quotes) From: pierre.php@gmail.com (Pierre) On 3/7/06, Zeev Suraski wrote: > The point is that breakage is aggregated, not binary. The more stuff > we break, the more difficult it is to port, and frankly, it's quite > likely that a non OO app could migrate fairly cleanly even to PHP 6 > with unicode disabled (perhaps with minor > fixes). get_magic_quotes_gpc() is designed for apps to do something > differently depending on the value of magic_quotes_gpc. It's fine > that it's always off in PHP 6, but there's no reason not to keep this > function (to always return false) so that you don't have to fix God > knows how many lines of code to remove it. Fair enough, as I said in my last post in the magic_quotes thread, it is easy to keep this function. I will modify the patch to keep the related functions (returning always false). Is is ok? Now about the ini entries, ini_get("removed_entry") will always return 0 (false), which is exactly the same as an entry set to off. Do we really want a E_CORE_ERROR if they are still set to on or used? --Pierre