[PHP-DEV] Re: [PHP-CVS] cvs: php-src(PHP_5_2) / php.ini-dist php.ini-recommended
Hi Dmitry, On 12/21/06, Dmitry Stogov [EMAIL PROTECTED] wrote: dmitry Thu Dec 21 13:05:28 2006 UTC Modified files: (Branch: PHP_5_2) /php-srcphp.ini-dist php.ini-recommended Log: Fixed comments http://cvs.php.net/viewvc.cgi/php-src/php.ini-dist?r1=1.231.2.10.2.14r2=1.231.2.10.2.15diff_format=u Index: php-src/php.ini-dist diff -u php-src/php.ini-dist:1.231.2.10.2.14 php-src/php.ini-dist:1.231.2.10.2.15 --- php-src/php.ini-dist:1.231.2.10.2.14Thu Dec 21 09:12:42 2006 +++ php-src/php.ini-distThu Dec 21 13:05:27 2006 @@ -254,7 +254,7 @@ max_execution_time = 30 ; Maximum execution time of each script, in seconds max_input_time = 60; Maximum amount of time each script may spend parsing request data -memory_limit = 128M ; Maximum amount of memory a script may consume (16MB) +memory_limit = 128M ; Maximum amount of memory a script may consume (128MB) By the way, why do we need to increase it again in 5.2 during the RC phase? I'm not really concerned about this change but I know many who will be or will complain. --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src(PHP_5_2) / php.ini-dist php.ini-recommended
On 12/21/06, Pierre [EMAIL PROTECTED] wrote: Hi Dmitry, On 12/21/06, Dmitry Stogov [EMAIL PROTECTED] wrote: dmitry Thu Dec 21 13:05:28 2006 UTC Modified files: (Branch: PHP_5_2) /php-srcphp.ini-dist php.ini-recommended Log: Fixed comments http://cvs.php.net/viewvc.cgi/php-src/php.ini-dist?r1=1.231.2.10.2.14r2=1.231.2.10.2.15diff_format=u Index: php-src/php.ini-dist diff -u php-src/php.ini-dist:1.231.2.10.2.14 php-src/php.ini-dist:1.231.2.10.2.15 --- php-src/php.ini-dist:1.231.2.10.2.14Thu Dec 21 09:12:42 2006 +++ php-src/php.ini-distThu Dec 21 13:05:27 2006 @@ -254,7 +254,7 @@ max_execution_time = 30 ; Maximum execution time of each script, in seconds max_input_time = 60; Maximum amount of time each script may spend parsing request data -memory_limit = 128M ; Maximum amount of memory a script may consume (16MB) +memory_limit = 128M ; Maximum amount of memory a script may consume (128MB) By the way, why do we need to increase it again in 5.2 during the RC phase? I'm not really concerned about this change but I know many who will be or will complain. And I sure am one of them. We are talking about _default_ settings, not edge cases. 128M is insane _default_ setting. -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src(PHP_5_2) / php.ini-dist php.ini-recommended
Hannes Magnusson wrote: And I sure am one of them. We are talking about _default_ settings, not edge cases. 128M is insane _default_ setting. Having in mind how short-lived most of the PHP processes are, I see really nothing wrong with setting a default limit to 128 MB, and I definitely don't see anything insane about it. Edin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src(PHP_5_2) / php.ini-dist php.ini-recommended
On 12/21/06, Edin Kadribasic [EMAIL PROTECTED] wrote: Hannes Magnusson wrote: And I sure am one of them. We are talking about _default_ settings, not edge cases. 128M is insane _default_ setting. Having in mind how short-lived most of the PHP processes are, I see really nothing wrong with setting a default limit to 128 MB, and I definitely don't see anything insane about it. How fast are you expecting to use up 128MB exactly and how? Unless we have a serious memory leak in every single function I can't see how the general PHP script is ever going to reach even 64M. -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: [PHP-CVS] cvs: php-src(PHP_5_2) / php.ini-dist php.ini-recommended
Oh sorry, you probably wasn't in the list. The discussion took place in @security. Now PHP is always compiled with --enable-memory-limit, and this is the reason to increase the default limit. Dmitry. -Original Message- From: Pierre [mailto:[EMAIL PROTECTED] Sent: Thursday, December 21, 2006 4:16 PM To: Dmitry Stogov Cc: PHP internals Subject: [PHP-DEV] Re: [PHP-CVS] cvs: php-src(PHP_5_2) / php.ini-dist php.ini-recommended Hi Dmitry, On 12/21/06, Dmitry Stogov [EMAIL PROTECTED] wrote: dmitry Thu Dec 21 13:05:28 2006 UTC Modified files: (Branch: PHP_5_2) /php-srcphp.ini-dist php.ini-recommended Log: Fixed comments http://cvs.php.net/viewvc.cgi/php-src/php.ini-dist?r1=1.231.2.10.2.14; r2=1.231.2.10.2.15diff_format=u Index: php-src/php.ini-dist diff -u php-src/php.ini-dist:1.231.2.10.2.14 php-src/php.ini-dist:1.231.2.10.2.15 --- php-src/php.ini-dist:1.231.2.10.2.14Thu Dec 21 09:12:42 2006 +++ php-src/php.ini-distThu Dec 21 13:05:27 2006 @@ -254,7 +254,7 @@ max_execution_time = 30 ; Maximum execution time of each script, in seconds max_input_time = 60; Maximum amount of time each script may spend parsing request data -memory_limit = 128M ; Maximum amount of memory a script may consume (16MB) +memory_limit = 128M ; Maximum amount of memory a script may consume (128MB) By the way, why do we need to increase it again in 5.2 during the RC phase? I'm not really concerned about this change but I know many who will be or will complain. --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src(PHP_5_2) / php.ini-dist php.ini-recommended
On 12/21/06, Dmitry Stogov [EMAIL PROTECTED] wrote: Oh sorry, you probably wasn't in the list. The discussion took place in @security. What exactly has increasing the default limit by factor of 4 have to do with security? Now PHP is always compiled with --enable-memory-limit, and this is the reason to increase the default limit. So it was acceptable limit when you had to enable it but now when its always enabled memory usage has suddenly increased dramatically? -Hannes Dmitry. -Original Message- From: Pierre [mailto:[EMAIL PROTECTED] Sent: Thursday, December 21, 2006 4:16 PM To: Dmitry Stogov Cc: PHP internals Subject: [PHP-DEV] Re: [PHP-CVS] cvs: php-src(PHP_5_2) / php.ini-dist php.ini-recommended Hi Dmitry, On 12/21/06, Dmitry Stogov [EMAIL PROTECTED] wrote: dmitry Thu Dec 21 13:05:28 2006 UTC Modified files: (Branch: PHP_5_2) /php-srcphp.ini-dist php.ini-recommended Log: Fixed comments http://cvs.php.net/viewvc.cgi/php-src/php.ini-dist?r1=1.231.2.10.2.14; r2=1.231.2.10.2.15diff_format=u Index: php-src/php.ini-dist diff -u php-src/php.ini-dist:1.231.2.10.2.14 php-src/php.ini-dist:1.231.2.10.2.15 --- php-src/php.ini-dist:1.231.2.10.2.14Thu Dec 21 09:12:42 2006 +++ php-src/php.ini-distThu Dec 21 13:05:27 2006 @@ -254,7 +254,7 @@ max_execution_time = 30 ; Maximum execution time of each script, in seconds max_input_time = 60; Maximum amount of time each script may spend parsing request data -memory_limit = 128M ; Maximum amount of memory a script may consume (16MB) +memory_limit = 128M ; Maximum amount of memory a script may consume (128MB) By the way, why do we need to increase it again in 5.2 during the RC phase? I'm not really concerned about this change but I know many who will be or will complain. --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Dumping support for Windows 98 and Windows ME
+1. I still get comments on my blog entry about this every so often: http://netevil.org/node.php?nid=336SC=1#comments The argument for keeping support is mostly about cost; I think it's clear that people that are serious about PHP can either use linux for free or pay for a more recent version of windows. --Wez. On 12/20/06, Andi Gutmans [EMAIL PROTECTED] wrote: Hi all, In the spirit of dumping Win95 support in PHP 5, I'd like to officialy dump Windows 98ME support from this point onwards. We are sticking to old Windows APIs because of this support which doesn't make much sense considering that Microsoft has stopped supporting those platforms six months ago (http://www.microsoft.com/windows/support/endofsupport.mspx). So I see no reason for us to support Micorsoft customers better than they do :) Those who are stuck on those versions should just stick to the versions up to PHP 5.2.0. They are not getting Windows updates, so why should they get PHP updates? Unless anyone disagrees with this, we'll go ahead with this. Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src(PHP_5_2) / php.ini-dist php.ini-recommended
When enabling restrictions like this, you need to consider the impact that you'll have on people that previously ran without any memory limit. The goal here is to strike a balance between a fair ballpark amount that won't break most scripts while preventing accidental (or otherwise) runaway memory allocation. 128MB is an example of a fair ballpark number. --Wez. On 12/21/06, Hannes Magnusson [EMAIL PROTECTED] wrote: On 12/21/06, Dmitry Stogov [EMAIL PROTECTED] wrote: Oh sorry, you probably wasn't in the list. The discussion took place in @security. What exactly has increasing the default limit by factor of 4 have to do with security? Now PHP is always compiled with --enable-memory-limit, and this is the reason to increase the default limit. So it was acceptable limit when you had to enable it but now when its always enabled memory usage has suddenly increased dramatically? -Hannes Dmitry. -Original Message- From: Pierre [mailto:[EMAIL PROTECTED] Sent: Thursday, December 21, 2006 4:16 PM To: Dmitry Stogov Cc: PHP internals Subject: [PHP-DEV] Re: [PHP-CVS] cvs: php-src(PHP_5_2) / php.ini-dist php.ini-recommended Hi Dmitry, On 12/21/06, Dmitry Stogov [EMAIL PROTECTED] wrote: dmitry Thu Dec 21 13:05:28 2006 UTC Modified files: (Branch: PHP_5_2) /php-srcphp.ini-dist php.ini-recommended Log: Fixed comments http://cvs.php.net/viewvc.cgi/php-src/php.ini-dist?r1=1.231.2.10.2.14; r2=1.231.2.10.2.15diff_format=u Index: php-src/php.ini-dist diff -u php-src/php.ini-dist:1.231.2.10.2.14 php-src/php.ini-dist:1.231.2.10.2.15 --- php-src/php.ini-dist:1.231.2.10.2.14Thu Dec 21 09:12:42 2006 +++ php-src/php.ini-distThu Dec 21 13:05:27 2006 @@ -254,7 +254,7 @@ max_execution_time = 30 ; Maximum execution time of each script, in seconds max_input_time = 60; Maximum amount of time each script may spend parsing request data -memory_limit = 128M ; Maximum amount of memory a script may consume (16MB) +memory_limit = 128M ; Maximum amount of memory a script may consume (128MB) By the way, why do we need to increase it again in 5.2 during the RC phase? I'm not really concerned about this change but I know many who will be or will complain. --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src(PHP_5_2) / php.ini-dist php.ini-recommended
On 12/21/06, Wez Furlong [EMAIL PROTECTED] wrote: When enabling restrictions like this, you need to consider the impact that you'll have on people that previously ran without any memory limit. The goal here is to strike a balance between a fair ballpark amount that won't break most scripts while preventing accidental (or otherwise) runaway memory allocation. 128MB is an example of a fair ballpark number. Point taken, but do we really want send out the message we expect the normal php script to take up to 128MB ram by changing php.ini-recommended? -Hannes --Wez. On 12/21/06, Hannes Magnusson [EMAIL PROTECTED] wrote: On 12/21/06, Dmitry Stogov [EMAIL PROTECTED] wrote: Oh sorry, you probably wasn't in the list. The discussion took place in @security. What exactly has increasing the default limit by factor of 4 have to do with security? Now PHP is always compiled with --enable-memory-limit, and this is the reason to increase the default limit. So it was acceptable limit when you had to enable it but now when its always enabled memory usage has suddenly increased dramatically? -Hannes Dmitry. -Original Message- From: Pierre [mailto:[EMAIL PROTECTED] Sent: Thursday, December 21, 2006 4:16 PM To: Dmitry Stogov Cc: PHP internals Subject: [PHP-DEV] Re: [PHP-CVS] cvs: php-src(PHP_5_2) / php.ini-dist php.ini-recommended Hi Dmitry, On 12/21/06, Dmitry Stogov [EMAIL PROTECTED] wrote: dmitry Thu Dec 21 13:05:28 2006 UTC Modified files: (Branch: PHP_5_2) /php-srcphp.ini-dist php.ini-recommended Log: Fixed comments http://cvs.php.net/viewvc.cgi/php-src/php.ini-dist?r1=1.231.2.10.2.14; r2=1.231.2.10.2.15diff_format=u Index: php-src/php.ini-dist diff -u php-src/php.ini-dist:1.231.2.10.2.14 php-src/php.ini-dist:1.231.2.10.2.15 --- php-src/php.ini-dist:1.231.2.10.2.14Thu Dec 21 09:12:42 2006 +++ php-src/php.ini-distThu Dec 21 13:05:27 2006 @@ -254,7 +254,7 @@ max_execution_time = 30 ; Maximum execution time of each script, in seconds max_input_time = 60; Maximum amount of time each script may spend parsing request data -memory_limit = 128M ; Maximum amount of memory a script may consume (16MB) +memory_limit = 128M ; Maximum amount of memory a script may consume (128MB) By the way, why do we need to increase it again in 5.2 during the RC phase? I'm not really concerned about this change but I know many who will be or will complain. --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src(PHP_5_2) / php.ini-dist php.ini-recommended
On 21-Dec-06, at 9:40 AM, Hannes Magnusson wrote: On 12/21/06, Wez Furlong [EMAIL PROTECTED] wrote: When enabling restrictions like this, you need to consider the impact that you'll have on people that previously ran without any memory limit. The goal here is to strike a balance between a fair ballpark amount that won't break most scripts while preventing accidental (or otherwise) runaway memory allocation. 128MB is an example of a fair ballpark number. Point taken, but do we really want send out the message we expect the normal php script to take up to 128MB ram by changing php.ini-recommended? Its not about sending a message, it is about preventing breakage of existing applications. Ilia Alshanetsky -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Query on assert_options() api
Andy Wharmby wrote:
Hi Internals
A colleague of mine is currently working on creating new test
cases to improve the coverage of the PHP test cases and whilst
attempting to
write new tests for the assert extension hit on a problem when
attempting to query the current setting of ASSERT_CALLBACK. using the
assert_options() api.
With the following simple testcase :
?php
function andy()
{
echo andy called\n;
}
$o = assert_options(ASSERT_CALLBACK, andy); /* SET */
$n = assert_options(ASSERT_CALLBACK); /* INQ */
echo old setting is $o\n;
echo new setting is $n\n; ?
The expected result was that the old (if any) and new setting of the
callback function name would be displayed but the actual results was
old setting is 1
new setting is 1
Looking at the code this is no surprise as the code in assert.c which
processes these requests unconditionally returns with RETURN_TRUE.
For all other assert options other than assert_options() function
returns the old value of the specified option as documented in the PHP
manual.
Further investigation uncovered that the code actually did behave in
the way we expected until it was changed to accept the array($obj,
methodname)
syntax back in July 2001 (revision 1.32 of assert.c). At this time the
return was changed to be unconditionally TRUE.
Unfortunately this makes writing a test case to query the current
setting of the ASSERT_CALLBACK option impossible as assert_options()
no longer returns
any useable information for this option, i.e to code a testcase as
above that sets a value and then checks its set as expected.
If the code is modified as in the attached patch to instead return the
ZVAL for the ASSERT_CALLBACK option then we are able create the new
testcase to
verify the assert_options() api. However, I am concerned there is a
good reason this was not done when the code was changed back in
2001.Can anyone think
of a good reason why returning the zval on this api is not a good idea ?
Any comments on my proposed fix appreciated.
Regards
Andy
Andy Wharmby
IBM United Kingdom Limited
Hi All,
I have now completed further testing on the patch I posted
yesterday and have uncovered a further defect that will need addressing
if the
earlier fix is accepted.
With the code modified such that assert_options(ASSERT_CALLBACK) returns
the current setting of the option it uncovers a problem with
a recent change to assert.c to fix defect 39718 (
http://bugs.php.net/bug.php?id=39718).
With the following simple script
?php
function andy()
{
echo andy called;
}
function default_callback()
{
echo default_calback called;
}
/* Check php.ini setting set */
$o = assert_options(ASSERT_CALLBACK);
echo Initial setting is \$o\ ...it should be default_callback!!!\n;
assert(0);
/* modify callback */
$o= assert_options(ASSERT_CALLBACK, andy);
assert(0);
?
and the following php.ini setting:
assert.callback=default_callback
then the expected result is:
Initial setting is default_callback ...it should be default_callback!!!
default_calback called
Warning: assert(): Assertion failed in
C:\Eclipse-PHP\workspace\Testcases\assertbug.php on line 16
andy called
Warning: assert(): Assertion failed in
C:\Eclipse-PHP\workspace\Testcases\assertbug.php on line 20
the actual result though is
Initial setting is...it should be default_callback!!!
default_calback called
Warning: assert(): Assertion failed in
C:\Eclipse-PHP\workspace\Testcases\assert
bug.php on line 16
andy called
Warning: assert(): Assertion failed in
C:\Eclipse-PHP\workspace\Testcases\assert
bug.php on line 20
Rather than getting the php.ini setting of default_callback returned
NULL is returned instead. Issuing assert() calls the expected callback
OK though.
The problem is that the value of the global ASSERTG(cb) is not copied
to ASSERTG(callback) until the first call to assert() by a request
so if the script includes a query on the setting BEFORE the first call
to assert() then the value returned is the default INI setting, i.e.
NULL, rather
than any value specified in php.ini. The issues is easily addressed by
moving the code that populates ASSERTG(callback) to a new RINIT function
in assert.c.
The modified patches for all the necessary changes to assert.c and
basic_functions.c are attached. If the fix is accepted I will get my
colleague to drop the
updated PHPT tests into CVS.
If a defect needs to be opened for this issue just let me know and I
will do so.
Regards
Andy
Andy Wharmby
IBM United Kingdom Limited
--- assert.c.old2006-12-03 17:30:54.0 +
+++ assert.c2006-12-21 13:26:35.71875 +
@@ -114,6 +114,17 @@
return SUCCESS;
}
+PHP_RINIT_FUNCTION(assert)
+{
+ if (ASSERTG(cb)) {
+ MAKE_STD_ZVAL(ASSERTG(callback));
+ ZVAL_STRING(ASSERTG(callback), ASSERTG(cb), 1);
+ }
+
+ return SUCCESS;
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src(PHP_5_2) / php.ini-dist php.ini-recommended
On Thu, 21 Dec 2006, Hannes Magnusson wrote: On 12/21/06, Edin Kadribasic [EMAIL PROTECTED] wrote: Hannes Magnusson wrote: And I sure am one of them. We are talking about _default_ settings, not edge cases. 128M is insane _default_ setting. Having in mind how short-lived most of the PHP processes are, I see really nothing wrong with setting a default limit to 128 MB, and I definitely don't see anything insane about it. How fast are you expecting to use up 128MB exactly and how? It goes pretty fast if you do some command line data munging. As memory limit is now enabled by default we should atleast have some usefull default for this setting. regards, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Dumping support for Windows 98 and Windows ME
+1 It might be a good idea to keep the latest build of php4/5, that can run on these systems, arround for a while so the users can download them. - Frank Hi all, In the spirit of dumping Win95 support in PHP 5, I'd like to officialy dump Windows 98ME support from this point onwards. We are sticking to old Windows APIs because of this support which doesn't make much sense considering that Microsoft has stopped supporting those platforms six months ago (http://www.microsoft.com/windows/support/endofsupport.mspx). So I see no reason for us to support Micorsoft customers better than they do :) Those who are stuck on those versions should just stick to the versions up to PHP 5.2.0. They are not getting Windows updates, so why should they get PHP updates? Unless anyone disagrees with this, we'll go ahead with this. Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Dumping support for Windows 98 andWindows ME
Yep, they are available at http://museum.php.net/ We might want to put a more prominent link on http://www.php.net/downloads.php to that page w/ an explanation. Andi -Original Message- From: Frank M. Kromann [mailto:[EMAIL PROTECTED] Sent: Thursday, December 21, 2006 2:20 PM To: Andi Gutmans Cc: 'PHP internals' Subject: Re: [PHP-DEV] Dumping support for Windows 98 andWindows ME +1 It might be a good idea to keep the latest build of php4/5, that can run on these systems, arround for a while so the users can download them. - Frank Hi all, In the spirit of dumping Win95 support in PHP 5, I'd like to officialy dump Windows 98ME support from this point onwards. We are sticking to old Windows APIs because of this support which doesn't make much sense considering that Microsoft has stopped supporting those platforms six months ago (http://www.microsoft.com/windows/support/endofsupport.mspx). So I see no reason for us to support Micorsoft customers better than they do :) Those who are stuck on those versions should just stick to the versions up to PHP 5.2.0. They are not getting Windows updates, so why should they get PHP updates? Unless anyone disagrees with this, we'll go ahead with this. Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Patch: recursive call to __get() error
Hello,
This patch for 5.2 provides an alternative error when you accidentally call
__get() recursively when trying to access some property of a class.
Currently, PHP says:
Notice: Undefined property: someClass::$someProperty
which makes it seem as though __get() is not called at all. This patch changes
the error to:
Warning: Recursive call to __get() trying to read property:
someClass::$someProperty
regards,
Peter
--- Zend.original/zend_object_handlers.cFri Dec 22 10:36:32 2006
+++ Zend/zend_object_handlers.c Fri Dec 22 10:47:29 2006
@@ -325,30 +325,40 @@
zend_guard *guard;
if (zobj-ce-__get
- zend_get_property_guard(zobj, property_info, member,
guard) == SUCCESS
- !guard-in_get) {
- /* have getter - try with it! */
- guard-in_get = 1; /* prevent circular getting */
- rv = zend_std_call_getter(object, member TSRMLS_CC);
- guard-in_get = 0;
+ zend_get_property_guard(zobj, property_info, member,
guard) == SUCCESS)
{
+ /* only if not already in __get() */
+ if(!guard-in_get) {
+ /* have getter - try with it! */
+ guard-in_get = 1; /* prevent circular getting
*/
+ rv = zend_std_call_getter(object, member
TSRMLS_CC);
+ guard-in_get = 0;
- if (rv) {
- retval = rv;
- if (type == BP_VAR_W || type == BP_VAR_RW ||
type == BP_VAR_UNSET) {
- if (rv-refcount 0) {
- zval *tmp = rv;
+ if (rv) {
+ retval = rv;
+ if (type == BP_VAR_W || type ==
BP_VAR_RW || type == BP_VAR_UNSET) {
+ if (rv-refcount 0) {
+ zval *tmp = rv;
- ALLOC_ZVAL(rv);
- *rv = *tmp;
- zval_copy_ctor(rv);
- rv-is_ref = 0;
- rv-refcount = 0;
- }
- if (Z_TYPE_P(rv) != IS_OBJECT) {
- zend_error(E_NOTICE, Indirect
modification of overloaded property
%s::$%s has no effect, zobj-ce-name, Z_STRVAL_P(member));
+ ALLOC_ZVAL(rv);
+ *rv = *tmp;
+ zval_copy_ctor(rv);
+ rv-is_ref = 0;
+ rv-refcount = 0;
+ }
+ if (Z_TYPE_P(rv) != IS_OBJECT) {
+ zend_error(E_NOTICE,
Indirect modification of overloaded property
%s::$%s has no effect, zobj-ce-name, Z_STRVAL_P(member));
+ }
}
+ } else {
+ retval = EG(uninitialized_zval_ptr);
+ }
+ }
+ else {
+ /* already in __get() */
+ if (!silent) {
+ zend_error(E_WARNING, Recursive call
to __get() trying to read property:
%s::$%s,
+ zobj-ce-name,
Z_STRVAL_P(member));
}
- } else {
retval = EG(uninitialized_zval_ptr);
}
} else {
Send instant messages to your online friends http://au.messenger.yahoo.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH] Small date() optimization
Hi, Just a simple patch for 5.2 to save smart_str_appends()'s strlen() calls in date_format(). It's already done in HEAD. Seems pretty safe for 5.2.1. :-) I also noticed that if the format string contains a backslash as the last character, it is lost (should be printed right?). So I changed that too and attached the patch for HEAD. 5.2's patch: http://realplain.com/php/date_optimization_5_2.diff Matt Index: ext/date/php_date.c === RCS file: /repository/php-src/ext/date/php_date.c,v retrieving revision 1.126 diff -u -r1.126 php_date.c --- ext/date/php_date.c 11 Dec 2006 21:08:44 - 1.126 +++ ext/date/php_date.c 22 Dec 2006 04:50:00 - @@ -926,7 +926,7 @@ break; case 'U': length = date_spprintf(buffer, 32 TSRMLS_CC, %lld, (timelib_sll) t-sse); break; - case '\\': if (i format_len) i++; length = date_spprintf(buffer, 32 TSRMLS_CC, %c, format[i]); break; + case '\\': if (i + 1 format_len) i++; /* break intentionally missing */ default: length = date_spprintf(buffer, 32 TSRMLS_CC, %c, format[i]); break; -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
