Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:100651
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain me.com designates 17.142.194.252 as permitted sender)
Date: Fri, 15 Sep 2017 22:41:27 +0200
To: PHP internals <internals@lists.php.net>,
 Stanislav Malyshev <smalyshev@gmail.com>
Message-ID: <9464fa46-8a8e-49ab-82e0-21954dd75aed@Spark>
In-reply-to: <a25a7575-e355-40eb-7977-e55145726085@gmail.com>
References: <097578bf-ab74-44cf-a465-dc6fdd50930f@Spark>
 <a25a7575-e355-40eb-7977-e55145726085@gmail.com>
MIME-version: 1.0
Content-type: multipart/alternative; boundary=59bc3cdd_6b8b4567_79ec
Subject: Re: [PHP-DEV] [RFC] Deprecate the extract function in PHP 7.3
From: ilija.tovilo@me.com

--59bc3cdd_6b8b4567_79ec
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hi Stas

Dangerous meaning that if given untrusted input someone could mess with t=
he behaviour of your code. There are risks and benefits to every solution=
. Certainly you=E2=80=99d agree that in some cases the risks outweigh the=
 benefits.

As Sara pointed out, this might not be the case here as there=E2=80=99s n=
o obvious way of mimicking =60extract=60s behaviour without introducing a=
t least one local variable that could be overwritten.

Thanks for the feedback everybody=21

Regards


On 15 Sep 2017, 22:10 +0200, Stanislav Malyshev <smalyshev=40gmail.com>, =
wrote:
> Hi=21
>
> > As a second parameter the =60extract=60 function takes some options t=
o
> > make this function less dangerous, like =60EXTR=5FSKIP=60 that
>
> I'd start with specifying what exactly is =22dangerous=22 in this funct=
ion.
> So far I don't see any specific danger. You can shoot yourself in the
> foot, so you can with many other tools in the language.
>
> > I seriously doubt the usefulness of this function, especially looking=

> > at the potential risks. The fact that overwriting the local variables=

>
> Which risks=3F This function is used by real-life code, and unless you =
do
> something like extract(=24=5FGET) in global scope I don't see any probl=
em.
> With extract(=24=5FGET) we could then also propose to remove all file
> functions because fopen(=24=5FGET=5B'filename'=5D) or unlink(=24=5FGET=5B=
'filename'=5D)
> are also dangerous. But if you use it properly, I don't see what =22ris=
ks=22
> are there.
>
> > Any thoughts=3F
>
> -1 so far, I don't see what problem you are trying to solve.
>
> --
> Stas Malyshev
> smalyshev=40gmail.com

--59bc3cdd_6b8b4567_79ec--