On Sat, Feb 4, 2012 at 8:20 PM, Clint Byrum cl...@ubuntu.com wrote:
hi,
So, I think I could probably put myself in as somebody that would support
an effort to bring Suhosin's mitigations into PHP core. I don't know
that the greater Ubuntu roject could devote many man-hours to it, but
perhaps
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
On Sun, Feb 5, 2012 at 5:23 PM, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 02/05/2012 02:49 AM, Ferenc Kovacs wrote:
Hi Rasmus,
I see that you are fixing tests in the 5.4 branch, however I was told by
Stas that I should hold my test fixes until the release:
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,
As many of you know we made huge improvements in PHP 5.4 memory usage
(enabling higher concurrency) and runtime performance.
Here are the unit test results for https://github.com/xp-framework/xp-framework
and https://github.com/xp-framework/xp-language after applying workarounds for
two
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.
As many of you know we made huge improvements in PHP 5.4 memory usage (enabling
higher concurrency) and runtime performance.
We've done our own benchmarks but it'd be great to hear from others re: what
you're seeing with your real-world apps.
Zend Framework API documentation generated by
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
Am 05.02.2012 21:34, schrieb Jaroslav Hanslik:
PHP 5.3.10 - Total time: 777 seconds, used: 316 MB RAM
PHP 5.4.0RC7 - Total time: 452 seconds, used: 156 MB RAM
phpDox, initial run for Zend Framework 2
PHP 5.4: Time: 54 seconds, Memory: 30.50Mb
PHP 5.3: Time: 01:09, Memory: 42.25Mb
Hi!
Another thing - is there any way to give CLANG some hints about some
functions - such as the fact that zend_error(E_ERROR) does not return or
just make some exceptions when we know some situation that it thinks can
happen does not in fact happen - such as revtal_ptr_ptr = retval_ptr
and
You cannot use Travis CI to compare for runtime of php5.4 and 5.3 since the
used boxes are propably either different and also under high load due to
virtualization, but you can check for memory differences. And they are huge:
Doctrine 2:
5.3: http://travis-ci.org/#!/doctrine/doctrine2/jobs/593850
On Sun, 05 Feb 2012 14:08:17 -0800, Stas Malyshev wrote:
Another thing - is there any way to give CLANG some hints about some
functions - such as the fact that zend_error(E_ERROR) does not return
or just make some exceptions when we know some situation that it
thinks can happen does not in fact
On 2/5/12 10:26 AM, Timm Friebe wrote:
Hi,
As many of you know we made huge improvements in PHP 5.4 memory usage
(enabling higher concurrency) and runtime performance.
Here are the unit test results for https://github.com/xp-framework/xp-framework
and
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 17:08, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
Another thing - is there any way to give CLANG some hints about some
functions - such as the fact that zend_error(E_ERROR) does not return or
just make some exceptions when we know some situation that it thinks can
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
On Mon, Feb 6, 2012 at 1:03 AM, Christopher Jones
christopher.jo...@oracle.com wrote:
Windows PHP 5.4 is built using profile-guided optimizations, but
PHP 5.3 isn't. My reading of Pierre's own benchmarks are that this
seems to be contributing significantly to the 5.4 gains on Windows.
It
Hi,
I've just rerun some synthetic and real-life benchmarks.
All the test were run on the same box (Linux, Core2 Duo 3GHz, 4GB RAM).
5.3 and 5.4 where configured and build with the same options and ran as
FastCGI server with the same number of processes and set of extensions.
PHP performance
33 matches
Mail list logo
