Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:100654
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 23:20:50 +0200
To: PHP internals <internals@lists.php.net>,
 Stanislav Malyshev <smalyshev@gmail.com>
Message-ID: <d35d5584-4656-451a-a562-1b7beee6a038@Spark>
In-reply-to: <f4544abc-4e74-d3da-470d-4f86bfd56ab8@gmail.com>
References: <097578bf-ab74-44cf-a465-dc6fdd50930f@Spark>
 <a25a7575-e355-40eb-7977-e55145726085@gmail.com>
 <9464fa46-8a8e-49ab-82e0-21954dd75aed@Spark>
 <f4544abc-4e74-d3da-470d-4f86bfd56ab8@gmail.com>
MIME-version: 1.0
Content-type: multipart/alternative; boundary=59bc4493_6b8b4567_7ae1
Subject: Re: [PHP-DEV] [RFC] Deprecate the extract function in PHP 7.3
From: ilija.tovilo@me.com

--59bc4493_6b8b4567_7ae1
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

> no, as there is no special risks

There certainly is. No other function (as far as I=E2=80=99m aware) mutat=
es your local symbol table. This means you need to know exactly what symb=
ols are defined and what kind of data you=E2=80=99ll receive when calling=
 =60extract=60. So basically this is only safe right at the beginning of =
your function, and even then it can override your other parameters. Even =
with trusted data this can hardly be considered safe.

=60=60=60
function foo(array =24data, =24bar) =7B
=C2=A0 =C2=A0 extract(=24data);
=C2=A0 =C2=A0 print(=24bar);
=7D

=24this->foo(=5B'bar' =3D> 'baz'=5D, 'bar=E2=80=99); // =E2=80=9Cbaz=22
=60=60=60

Regards


On 15 Sep 2017, 23:05 +0200, Stanislav Malyshev <smalyshev=40gmail.com>, =
wrote:
> Hi=21
>
> > Dangerous meaning that if given untrusted input someone could mess wi=
th
> > the behaviour of your code. There are risks and benefits to every
>
> Same as many other functions. Given untrusted input, unlink() could
> delete files on your hard drive, and file=5Fput=5Fcontents() could over=
write
> your data or send it to unauthorized party. That's not the reason to
> remove these functions.
>
> > solution. Certainly you=E2=80=99d agree that in some cases the risks =
outweigh
> > the benefits.
>
> In some cases, yes. In this case, no, as there is no special risks not
> existing in many other functions. Any function that has side effects
> could do something unexpected when you give it unexpected input. Since
> we're not converting PHP to be purely functional language just yet, the=

> solution is to use functions correctly, not remove them.
> --
> Stas Malyshev
> smalyshev=40gmail.com

--59bc4493_6b8b4567_7ae1--