Re: [RFC] Deprecate the extract function in PHP 7.3

From: Date: Fri, 15 Sep 2017 20:41:27 +0000
Subject: Re: [RFC] Deprecate the extract function in PHP 7.3
References: 1 2  Groups: php.internals 
Request: Send a blank email to internals+get-100651@lists.php.net to get a copy of this message
Hi Stas Dangerous meaning that if given untrusted input someone could mess with the behaviour of your code. There are risks and benefits to every solution.. Certainly you’d agree that in some cases the risks outweigh the benefits. As Sara pointed out, this might not be the case here as there’s no obvious way of mimicking extracts behaviour without introducing at least one local variable that could be overwritten. Thanks for the feedback everybody! Regards On 15 Sep 2017, 22:10 +0200, Stanislav Malyshev <smalyshev@gmail.com>, wrote: > Hi! > > > As a second parameter the extract function takes some > > options to > > make this function less dangerous, like EXTR_SKIP that > > I'd start with specifying what exactly is "dangerous" in this function. > 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? This function is used by real-life code, and unless you do > something like extract($_GET) in global scope I don't see any problem. > With extract($_GET) we could then also propose to remove all file > functions because fopen($_GET['filename']) or unlink($_GET['filename']) > are also dangerous. But if you use it properly, I don't see what "risks" > are there. > > > Any thoughts? > > -1 so far, I don't see what problem you are trying to solve. > > -- > Stas Malyshev > smalyshev@gmail.com

« previous php.internals (#100651) next »