Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:74371
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lerdorf.com from 209.85.192.45 cause and error)
Message-ID: <537A7ABF.6080201@lerdorf.com>
Date: Mon, 19 May 2014 14:42:23 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: Gary Mort <garyamort@gmail.com>, internals@lists.php.net
References: <537A62D6.6050704@gmail.com>
In-Reply-To: <537A62D6.6050704@gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="usXMIAftmvQnM86hh3na7MJunAvRXEpnm"
Subject: Re: [PHP-DEV] Globals, closures, and filter_input
From: rasmus@lerdorf.com (Rasmus Lerdorf)

--usXMIAftmvQnM86hh3na7MJunAvRXEpnm
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 5/19/14, 1:00 PM, Gary Mort wrote:
> This seems to me to be an odd combination and it is not explictly
> documented.
>=20
> I'm running under PHP 5.5.12
>=20
> First off, when after executing unset($_GET) - the global $_GET variabl=
e
> no longer exists.  However, calling filter_input(INPUT_GET,...)
> continues to return data from the query string.
>=20
> So filter_input and filter_has_var are independent of the $_GET
> variable.  IE they will return whatever the original data was.  This is=

> noted in the comments regarding these functions,
> http://us1.php.net/manual/en/function.filter-input.php  - I simply want=

> to double check that this is working as designed, and not a bug that
> will be corrected[since there is no spec for this feature. :-)]

That is working as designed. The whole point of the filter functions is
that they keep a copy of the original input and only expose a filtered
version in the GPC globals. When you need unfiltered data, or data
filtered with a different filter you can call the filter functions to do
so. That wouldn't work if the initial filter operation was destructive.

> However, global variables are not supposed to be bound to closures and
> objects, then this could result in future problems if that feature is
> ever modified.

I don't see why we would restrict the super globals from being bound to
closures in the future. I see nothing wrong with your approach.

-Rasmus


--usXMIAftmvQnM86hh3na7MJunAvRXEpnm
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - https://gpgtools.org

iEYEARECAAYFAlN6esAACgkQlxayKTuqOuDYVwCdGlY8lCsyj+wtw8zaWXlhq6S5
sk0AoIPCsY+JtGUw6r2yQqIHGj5cMsbc
=Pk08
-----END PGP SIGNATURE-----

--usXMIAftmvQnM86hh3na7MJunAvRXEpnm--