A couple people I respect a heck of a lot have voted against, but I've
heard no technical explanation of why from them...
I voted Yes because I've never found a need for /e at all,
personally. Not sure my vote even counts, so feel free to nuke it. :-)
Or maybe I'm just not smart enough to employ
+1: It does make sense to me for the same reason as Stas mentioned.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi internals!
I have written an RFC that proposes to *deprecate* and *remove* the /e modifier:
https://wiki.php.net/rfc/remove_preg_replace_eval_modifier
Comments welcome!
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
I think this is a good idea, since nobody's keeping you from calling
eval() in a callback if you really really really need to, there's no
loss of functionality, just the discouragement of an unhealthy worst
practice. (:
On Sun, Feb 5, 2012 at 9:59 AM, Nikita Popov nikita@googlemail.com wrote:
hi,
I think we should remove eval at the same time then. As the risk is
exactly the same in both situations. Eval is just as evil and can be
avoided as well (or any other similar features, not sure if other exts
allow that).
Cheers,
On Sun, Feb 5, 2012 at 3:59 PM, Nikita Popov
I know a straw man argument when I see one (:
/e suggests that eval is a casual thing to be sprinkled into typical
search and replace operations. It also suggests that putting PHP code
in a quoted string is probably the easy way to solve your problem.
It's often discovered before the developer
what he hell - if you kill eval you would kill the whole
work of my life and yes i know that eval is evil and
it is only used at one place which is a central and
real important to include modules and set parameters
dynamically
the /e modifier is a total other dimension because it can
be used by
A sense of humor is important when reading mailing lists frequented by
extremely clever people (:
On Sun, Feb 5, 2012 at 11:34 AM, Reindl Harald h.rei...@thelounge.net wrote:
what he hell - if you kill eval you would kill the whole
work of my life and yes i know that eval is evil and
it is
i did not see any smiley and without it is hard to smell
remove /e makes sense over the long because it is
really dangerous to get wrong used with user-input
by pepole CP reg-expressions from somewehre without exactly
understand what they are doing and that they can trigger
remote-code execution
Perhaps rather than killing it we should just emphasize it more in the
documentation (ie on preg_replace and not only in pattern modifiers).
But I have found the /e modifier to be very useful in the past. Unfortunately,
just having woken up I can't remember exactly where and how I used it,
On Sun, 5 Feb 2012, Nikita Popov wrote:
I have written an RFC that proposes to *deprecate* and *remove* the /e
modifier:
https://wiki.php.net/rfc/remove_preg_replace_eval_modifier
Comments welcome!
This RFC makes no sense. It says:
For example the above example can be used to execute
On Sun, 5 Feb 2012, Tom Boutell wrote:
A sense of humor is important when reading mailing lists frequented by
extremely clever people (:
Sarcasm doesn't work on mailinglists, so don't use it.
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation:
Am 05.02.2012 17:45, schrieb Michael Stowe:
Perhaps another option, if it's a security concern is the ability
to turn off the /e modifier, and have it off by default. This way
we can protect our less experienced programmers, while keeping it
available for more advanced use cases.
Just
On Sun, Feb 5, 2012 at 5:21 PM, Pierre Joye pierre@gmail.com wrote:
hi,
I think we should remove eval at the same time then. As the risk is
exactly the same in both situations. Eval is just as evil and can be
avoided as well (or any other similar features, not sure if other exts
allow
-Original Message-
From: Derick Rethans [mailto:der...@php.net]
Sent: Sunday, February 05, 2012 11:46 AM
To: Nikita Popov
Cc: PHP internals
Subject: Re: [PHP-DEV] [RFC] Deprecate and remove /e modifier from
preg_replace
On Sun, 5 Feb 2012, Nikita Popov wrote:
I have written
On Sun, Feb 5, 2012 at 5:45 PM, Michael Stowe mikegst...@gmail.com wrote:
[snip]
Perhaps another option, if it's a security concern is the ability to turn off
the /e modifier, and have it off by default. This way we can protect our less
experienced programmers, while keeping it available for
Am 05.02.2012 18:09, schrieb Nikita Popov:
On Sun, Feb 5, 2012 at 5:45 PM, Michael Stowe mikegst...@gmail.com wrote:
[snip]
Perhaps another option, if it's a security concern is the ability to turn
off the /e modifier, and have it off by default. This way we can protect our
less
hi,
On Sun, Feb 5, 2012 at 5:45 PM, Michael Stowe mikegst...@gmail.com wrote:
Perhaps another option, if it's a security concern is the ability to turn off
the /e modifier, and have it off by default. This way we can protect our less
experienced programmers, while keeping it available for
Hi!
That sounds like a nicer approach and it is actually one of the RFC I
like to see to bring some of the features of Suhosin in PHP (disable
eval and the e modifier).
Disbaling eval() makes little sense to me - nobody accidentally writes
an eval() and if you execute third-party code
Hi!
Removing this would obviously be an inconvenience for some people,
but getting your server hacked is also an inconvenience, and hackers
don't give you nice warnings with file and line number. I like the
idea of doing _something_ here. Deprecate now and remove later sounds
fair.
Deprecate and then remove, or just leave it in. Make it optional
forever just generates more nonportable PHP code. Ick.
On Sun, Feb 5, 2012 at 3:28 PM, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
Removing this would obviously be an inconvenience for some people,
but getting your server
On 6 February 2012 04:37, Tom Boutell t...@punkave.com wrote:
Deprecate and then remove, or just leave it in. Make it optional
forever just generates more nonportable PHP code. Ick.
Huge +1 to that.
Given the existence of preg_replace_callback() (as Stas noted above),
my preference is for
On Sun, Feb 5, 2012 at 19:32, Adam Harvey ahar...@php.net wrote:
On 6 February 2012 04:37, Tom Boutell t...@punkave.com wrote:
Deprecate and then remove, or just leave it in. Make it optional
forever just generates more nonportable PHP code. Ick.
Huge +1 to that.
Given the existence of
23 matches
Mail list logo
