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 emp
+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
On Sun, Feb 5, 2012 at 19:32, Adam Harvey wrote:
> On 6 February 2012 04:37, Tom Boutell 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 S
On 6 February 2012 04:37, Tom Boutell 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 deprecation and t
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 wrote:
> Hi!
>
>
>> Removing this would obviously be an inconvenience for some people,
>> but getting your server hacked is also
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.
Inconvenien
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 there's
hi,
On Sun, Feb 5, 2012 at 5:45 PM, Michael Stowe 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 more advanced use
Am 05.02.2012 18:09, schrieb Nikita Popov:
> On Sun, Feb 5, 2012 at 5:45 PM, Michael Stowe 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 programmer
On Sun, Feb 5, 2012 at 5:45 PM, Michael Stowe 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 more advanced use
> -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,
On Sun, Feb 5, 2012 at 5:21 PM, Pierre Joye 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).
>
> Cheer
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.
>
>
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: http://xde
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 exec
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, lol.
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 C&P reg-expressions from somewehre without exactly
understand what they are doing and that they can trigger
remote-code execution
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 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 only used at one place
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 pe
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 has
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 wrote:
> Hi inter
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 wrote:
> Hi internals!
>
> I h
22 matches
Mail list logo
