Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:35328
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain chiaraquartet.net from 38.99.98.18 cause and error)
Message-ID: <47AC8597.4060009@chiaraquartet.net>
Date: Fri, 08 Feb 2008 10:38:47 -0600
User-Agent: Thunderbird 2.0.0.6 (X11/20071022)
MIME-Version: 1.0
To: internals Mailing List <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: magic_quotes and the question of BC
From: greg@chiaraquartet.net (Gregory Beaver)

Hello all,

Those of you who are saying things like "forget the idiots using
magic_quotes" need to understand more clearly what is being proposed.
NOBODY is proposing keeping magic_quotes.

As of PHP 5.3 and earlier, all applications worth an ounce of anything
must check for and handle magic_quotes_runtime.  If magic_quotes_runtime
is enabled, and you don't handle it, you end up with a bunch of
unnecessary slashes in your input.

This is VERY different from relying upon magic_quotes_runtime to
"safely" escape crap.

If the magic_quotes functions are removed, this will unequivocably break
*every* decent application written for PHP 5 and PHP 4.  As an example,
the PEAR Installer uses a disabling routine even though it doesn't do
any web access at all.  Why?  Because magic_quotes_runtime affects
file_get_contents(), which is used to read registry files.  As such,
even though the magic_quotes functionality is never used, the app still
has to check for and disable it.

If the function magic_quotes_runtime() exists and simply returns false,
the PEAR installer continues to work as written without modification.  I
could certainly modify the latest release to use the if
(function_exists()) check that some have proposed, and that would be
fine for me, but it is not a good solution for the hundreds of thousands
of users we have out there.

Why?

First of all, very few people actually upgrade to the latest version
when it is released.  The majority have upgraded by approximately a
*year* after the release date, and a large minority (30% or so) do not
upgrade for up to 4 years.

Now, if Joe Shmoe has a slightly older version of PEAR, and upgrades to
PHP 6 (yes, people DO upgrade PHP and still keep their outdated PEAR
installations in spite of obvious reasons not to do this, and no, we
can't expect to change this from our perch here at php.net), suddenly
Joe gets a fatal error, and can no longer use PEAR either to upgrade to
a newer version or anything of that nature.  Joe wastes a ton of time
figuring out what is wrong, and ends up having to manually re-install PEAR.

Who would benefit from having the functions removed?  People who don't
use them don't care, people who do would get a fatal error.

Frankly, I don't see why there is any vote whatsoever.  It's plain
stupid to consider removing them when a fully backwards-compatible
solution exists that has no performance penalty, no security penalty,
and in fact no penalty at all.

There is never any benefit in making the upgrade path harder for our
users, come on people.

Greg