[PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_4/Zend/zend_execute_API.c trunk/Zend/zend_execute_API.c
Hi David,
When I was just checking PHP 5.4 compatibility with Xdebug I ran into
the case where zend_eval_string() no longer would bail out when you'd
evalulate something that doesn't work (like a standalone
$this-property; without being in a class scope).
Xdebug has code (simplified) like this:
intres = FAILURE;
zend_first_try {
res = zend_eval_string(eval_string, ret_zval, xdebug://debug-eval
TSRMLS_CC);
} zend_end_try();
return res;
This means that when zend_eval_string would cause an engine exception,
res would be FAILURE. It would only be true if zend_eval_string
succesfully completed.
However, after your patch, my res would still be set to SUCCESS. This
is because zend_execute's bailout is now caught by the zend_end_try that
you added:
int retval;
new_op_array = zend_compile_string(pv, string_name TSRMLS_CC);
if (new_op_array) {
zend_try { // new code
zend_execute(new_op_array TSRMLS_CC);
} zend_end_try(); // new code
retval = SUCCESS;
Obvious, the return value should not be SUCCESS if something incorrect
was tried to be eval'ed.
Your patch also changes the behaviour of zend_eval_string; which is
probably not a very big issue for many people, but it can easily be
addressed by the following patch:
Index: zend_execute_API.c
===
--- zend_execute_API.c (revision 322905)
+++ zend_execute_API.c (working copy)
@@ -1195,8 +1195,11 @@
}
CG(interactive) = 0;
+ retval = SUCCESS;
zend_try {
zend_execute(new_op_array TSRMLS_CC);
+ } zend_catch {
+ retval = FAILURE;
} zend_end_try();
CG(interactive) = orig_interactive;
@@ -1218,7 +1221,6 @@
destroy_op_array(new_op_array TSRMLS_CC);
efree(new_op_array);
EG(return_value_ptr_ptr) = original_return_value_ptr_ptr;
- retval = SUCCESS;
} else {
retval = FAILURE;
}
The patch just changes the setting of the return value around, and I think we
should include this in the upcoming RC.
cheers,
Derick
On Sat, 12 Nov 2011, David Soria Parra wrote:
dsp Sat, 12 Nov 2011 17:05:08 +
Revision: http://svn.php.net/viewvc?view=revisionrevision=319102
Log:
Fix #60218 (instantiating unknown class leads to memory leak in cli)
Bug: https://bugs.php.net/60218 (error getting bug information)
Changed paths:
U php/php-src/branches/PHP_5_4/Zend/zend_execute_API.c
U php/php-src/trunk/Zend/zend_execute_API.c
Modified: php/php-src/branches/PHP_5_4/Zend/zend_execute_API.c
===
--- php/php-src/branches/PHP_5_4/Zend/zend_execute_API.c 2011-11-12
16:32:10 UTC (rev 319101)
+++ php/php-src/branches/PHP_5_4/Zend/zend_execute_API.c 2011-11-12
17:05:08 UTC (rev 319102)
@@ -1195,7 +1195,9 @@
}
CG(interactive) = 0;
- zend_execute(new_op_array TSRMLS_CC);
+ zend_try {
+ zend_execute(new_op_array TSRMLS_CC);
+ } zend_end_try();
CG(interactive) = orig_interactive;
if (local_retval_ptr) {
Modified: php/php-src/trunk/Zend/zend_execute_API.c
===
--- php/php-src/trunk/Zend/zend_execute_API.c 2011-11-12 16:32:10 UTC (rev
319101)
+++ php/php-src/trunk/Zend/zend_execute_API.c 2011-11-12 17:05:08 UTC (rev
319102)
@@ -1195,7 +1195,9 @@
}
CG(interactive) = 0;
- zend_execute(new_op_array TSRMLS_CC);
+ zend_try {
+ zend_execute(new_op_array TSRMLS_CC);
+ } zend_end_try();
CG(interactive) = orig_interactive;
if (local_retval_ptr) {
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_4/Zend/zend_execute_API.c trunk/Zend/zend_execute_API.c
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Thank you for catching that. Please go ahead and commit!.
Thanks
On 01/28/2012 04:00 PM, Derick Rethans wrote:
Hi David,
When I was just checking PHP 5.4 compatibility with Xdebug I ran
into the case where zend_eval_string() no longer would bail out
when you'd evalulate something that doesn't work (like a standalone
$this-property; without being in a class scope).
Xdebug has code (simplified) like this:
intres = FAILURE;
zend_first_try { res = zend_eval_string(eval_string, ret_zval,
xdebug://debug-eval TSRMLS_CC); } zend_end_try();
return res;
This means that when zend_eval_string would cause an engine
exception, res would be FAILURE. It would only be true if
zend_eval_string succesfully completed.
However, after your patch, my res would still be set to SUCCESS.
This is because zend_execute's bailout is now caught by the
zend_end_try that you added:
int retval;
new_op_array = zend_compile_string(pv, string_name TSRMLS_CC);
if (new_op_array) {
zend_try { // new code zend_execute(new_op_array TSRMLS_CC); }
zend_end_try(); // new code
retval = SUCCESS;
Obvious, the return value should not be SUCCESS if something
incorrect was tried to be eval'ed.
Your patch also changes the behaviour of zend_eval_string; which is
probably not a very big issue for many people, but it can easily
be addressed by the following patch:
Index: zend_execute_API.c
===
- --- zend_execute_API.c(revision 322905)
+++ zend_execute_API.c(working copy) @@ -1195,8 +1195,11 @@ }
CG(interactive) = 0;
+ retval = SUCCESS; zend_try { zend_execute(new_op_array
TSRMLS_CC); + } zend_catch { +retval =
FAILURE; }
zend_end_try();
CG(interactive) = orig_interactive; @@ -1218,7 +1221,6 @@
destroy_op_array(new_op_array TSRMLS_CC); efree(new_op_array);
EG(return_value_ptr_ptr) = original_return_value_ptr_ptr; - retval
= SUCCESS; } else { retval = FAILURE; }
The patch just changes the setting of the return value around, and
I think we should include this in the upcoming RC.
cheers, Derick
On Sat, 12 Nov 2011, David Soria Parra wrote:
dsp Sat, 12 Nov 2011
17:05:08 +
Revision:
http://svn.php.net/viewvc?view=revisionrevision=319102
Log: Fix #60218 (instantiating unknown class leads to memory leak
in cli)
Bug: https://bugs.php.net/60218 (error getting bug information)
Changed paths: U
php/php-src/branches/PHP_5_4/Zend/zend_execute_API.c U
php/php-src/trunk/Zend/zend_execute_API.c
Modified: php/php-src/branches/PHP_5_4/Zend/zend_execute_API.c
===
- --- php/php-src/branches/PHP_5_4/Zend/zend_execute_API.c 2011-11-12
16:32:10 UTC (rev 319101)
+++ php/php-src/branches/PHP_5_4/Zend/zend_execute_API.c
2011-11-12 17:05:08 UTC (rev 319102) @@ -1195,7 +1195,9 @@ }
CG(interactive) = 0;
-zend_execute(new_op_array TSRMLS_CC); + zend_try { +
zend_execute(new_op_array TSRMLS_CC); + } zend_end_try();
CG(interactive) = orig_interactive; if (local_retval_ptr) {
Modified: php/php-src/trunk/Zend/zend_execute_API.c
===
- --- php/php-src/trunk/Zend/zend_execute_API.c 2011-11-12 16:32:10 UTC
(rev 319101)
+++ php/php-src/trunk/Zend/zend_execute_API.c2011-11-12 17:05:08
UTC (rev 319102) @@ -1195,7 +1195,9 @@ } CG(interactive) = 0;
-zend_execute(new_op_array TSRMLS_CC); + zend_try { +
zend_execute(new_op_array TSRMLS_CC); + } zend_end_try();
CG(interactive) = orig_interactive; if (local_retval_ptr) {
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJPJCpeAAoJEAT0aMuPE7Z1v1oP+wV/jLdUNwhLu5rlWgpGbSrP
31HdRF1OzwTA7WfkCh0Vj6J59iGFbwF/odZatXxMHvX++KPuPScveGtFsCXon3zv
4N2AfvulZrlaSgaxyB2KAII+JhqEH5fX1mqooz0Xqz8zeZXqCKSdCO0FJVWUIm+1
6qWc7WIhsB4nwRBNT/uCqMx2btFgcPLqW72iwfPw7uWTSUQfPW8vOpwsv+5LXMKd
2wHG9+6C+dQXQEBL+bWXetCKIPzL1Q28LnDr2iQKtS0qLA3p0fbRkpCt4VVUkQ6t
fO8tfZ26XIX9Ms3kQVFtQcwfNuQ47j8zmOSxVd14u2d2suYuXIYN8xpimgKU6xSM
q2INXZVtTjYenSAPLfLwFdQXb4RqTRk4Gtv2exTCZPqJDSw9WQgZ5KX6VoYilcN6
HkxT7i++13+RlUFr58RjE7DKSC7SQ3ZnHagxz9INm9wDl5CJGJMTkwWrTUhdh412
C5wHgLnxLJvAmhvFZnMfkgZF8YPEs82+cN7M6PFz7xVvmq++zmavb1icAvysvb1d
VSQ+V8N3WGPaprOzSbqQW8QFl2dUAOKKBJIrS8aPIsDHIlIv9UHuwiXCx4Y/51W8
llVGBzYTY9RLf9tZYsIobMw7WseH3N52K0KcmAsjzEu7RJeBuk/WFQf/9z+ufoMl
L/HF6eiz0eA+0F2pYA84
=EzEH
-END PGP SIGNATURE-
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP_SESSION_* constant values
Hello everyone, For the result of session_status(), the corresponding constants for the sessions state are - PHP_SESSION_DISABLED = 0 - PHP_SESSION_NONE = 1 - PHP_SESSION_ACTIVE = 2 I'd like to suggest we change these values to - PHP_SESSION_DISABLED = -1 - PHP_SESSION_NONE = 0 - PHP_SESSION_ACTIVE = 1 This way, one can do if(session_status()) to check if there is an active session, rather than having to compare the result to a constant. Any objections? Thanks, Justin Martin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP_SESSION_* constant values
On Sat, Jan 28, 2012 at 7:17 PM, Justin Martin frozenf...@php.net wrote: Hello everyone, For the result of session_status(), the corresponding constants for the sessions state are - PHP_SESSION_DISABLED = 0 - PHP_SESSION_NONE = 1 - PHP_SESSION_ACTIVE = 2 I'd like to suggest we change these values to - PHP_SESSION_DISABLED = -1 - PHP_SESSION_NONE = 0 - PHP_SESSION_ACTIVE = 1 This way, one can do if(session_status()) to check if there is an active session, rather than having to compare the result to a constant. Any objections? I believe comparing the value against a constant, is always more readable than wondering what truthy means. if(session_status() === PHP_SESSION_ACTIVE) is much self-documenting than the proposed change. Therefore I object to this change. - Paul Thanks, Justin Martin -- 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] Uploading a patch fails...
Hi! I'm trying to upload the latest getters/setters patch to: https://bugs.php.net/bug.php?id=49526 I get Uploaded file is empty or nothing was uploaded. Is there a problem or a file size limit? The patch file is 205k now. BTW, I would recommend using Wiki and RFC for tracking new features, especially of this magnitude. This is obviously not a bug, and not a small feature request either... -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP_SESSION_* constant values
Hi! I'd like to suggest we change these values to - PHP_SESSION_DISABLED = -1 - PHP_SESSION_NONE = 0 - PHP_SESSION_ACTIVE = 1 This way, one can do if(session_status()) to check if there is an active session, rather than having to compare the result to a constant. Any objections? Yes, there's no reason to do that since you can just compare to the constant - that's why they exist in the first place. Then gain of not typing couple of characters is much less than the confusion that would result from changing the constants. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP_SESSION_* constant values
I believe comparing the value against a constant, is always more readable than wondering what truthy means. if(session_status() === PHP_SESSION_ACTIVE) is much self-documenting than the proposed change. ... also an obvious BC break for anyone who was using the values instead of the constants before. Not that anyone should ever do this, but the change presupposes that people *do* use the values, so it basically contradicts its own acceptability as it is a breaking change! -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP_SESSION_* constant values
On Sat, Jan 28, 2012 at 9:14 PM, Sanford Whiteman swhitemanlistens-softw...@cypressintegrated.com wrote: I believe comparing the value against a constant, is always more readable than wondering what truthy means. if(session_status() === PHP_SESSION_ACTIVE) is much self-documenting than the proposed change. ... also an obvious BC break for anyone who was using the values instead of the constants before. Not that anyone should ever do this, but the change presupposes that people *do* use the values, so it basically contradicts its own acceptability as it is a breaking change! There is no BC change here as session_status() has been added in the 5_4 branch as far as i can tell. -- S. -- 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] PHP_SESSION_* constant values
There is no BC change here as session_status() has been added in the 5_4 branch as far as i can tell. OK, fair enough, I didn't understand it was trying to get into 5.4. -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: PHP_SESSION_* constant values
Someone actually just pointed out to me that if(-1) returns true. In that case, I suppose my suggestion doesn't quite work. The reason I suggest this is that I suspect people will constantly be looking up what the constants are called. On 12-01-28 11:17 AM, Justin Martin wrote: Hello everyone, For the result of session_status(), the corresponding constants for the sessions state are - PHP_SESSION_DISABLED = 0 - PHP_SESSION_NONE = 1 - PHP_SESSION_ACTIVE = 2 I'd like to suggest we change these values to - PHP_SESSION_DISABLED = -1 - PHP_SESSION_NONE = 0 - PHP_SESSION_ACTIVE = 1 This way, one can do if(session_status()) to check if there is an active session, rather than having to compare the result to a constant. Any objections? Thanks, Justin Martin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Uploading a patch fails...
BTW, I would recommend using Wiki and RFC for tracking new features, especially of this magnitude. This is obviously not a bug, and not a small feature request either... the RFC is already in the wiki, AFAIR it is linked from the ticket also. https://wiki.php.net/rfc/propertygetsetsyntax https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented -- Ferenc Kovács @Tyr43l - http://tyrael.hu -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PHP_SESSION_* constant values
Someone actually just pointed out to me that if(-1) returns true. In that case, I suppose my suggestion doesn't quite work. Well, it still works depending on what conclusion you want to draw in your local environment. Sessions_disabled || yes_active_session might go through the same code path, while no_active_session might go through another. -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Uploading a patch fails...
On 28/01/12 03:05, Rasmus Lerdorf wrote: There is a 100k limit, but the error message you are getting indicates that you aren't actually hitting that limitation. The server config has a 2M limit, so you should be fitting well within that. I'm not sure how your 200k patch is hittig that file is empty condition in the code. You mean upload_max_filesize is 2M? What about post_max_size ? That could well lead to that condition. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PHP_SESSION_* constant values
On Sat, Jan 28, 2012 at 9:53 PM, Justin Martin frozenf...@php.net wrote: Someone actually just pointed out to me that if(-1) returns true. In that case, I suppose my suggestion doesn't quite work. The reason I suggest this is that I suspect people will constantly be looking up what the constants are called. Encouraging people to check the manual is a good thing. As the constants are being used the user doesn't need to consult the manual at all as PHP_SESSION_DISABLED is very self-documenting. Again, a -1 from me. - Paul. On 12-01-28 11:17 AM, Justin Martin wrote: Hello everyone, For the result of session_status(), the corresponding constants for the sessions state are - PHP_SESSION_DISABLED = 0 - PHP_SESSION_NONE = 1 - PHP_SESSION_ACTIVE = 2 I'd like to suggest we change these values to - PHP_SESSION_DISABLED = -1 - PHP_SESSION_NONE = 0 - PHP_SESSION_ACTIVE = 1 This way, one can do if(session_status()) to check if there is an active session, rather than having to compare the result to a constant. Any objections? Thanks, Justin Martin -- 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] Symlinks in / don't work
Hey Dmitry, could you take a look at this one. I think this is mostly your code and I am a bit lost in the path manipulation that is going on here. This is bug https://bugs.php.net/51860 and it can be reproduced from cli like this: % cd / % ln -s / phptest % echo OK /phpfile % echo '?php include /phptest/phpfile;' /phpinc % php /phptest/phpinc And you will see that it can't find /phptest/phpfile But magically if you run it like this: % php phptest/phpinc it works fine. The problem is that /phptest gets cached without the directory bit set. And when we read it back from the cache and see it isn't a directory we obviously don't think it can contain a file. It works in the second case because of what is probably a secondary bug and that is that it ends up caching //phptest instead of /phptest. So in that case there is a cache miss on the include and it doesn't fail. However, if you add a second include that includes another file from /phptest then the first include would have caused /phptest to get cached and the second include will then fail. If you do this exact same test from /foo instead of from / then /foo/phptest which in this case is a symlink to /foo correctly gets cached with directory=1. So somewhere in the while(1) loop logic in tsrm_realpath_r() we fail to get to the point where we stat / and set the directory bit. Obviously if someone else wants to fire up gdb to find the likely off-by-one error that is causing this, please do. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] SOAP request user_agent field
As noted on bug #60887 SOAP does not send the user-agent field when requesting the wsdl Subsequent requests are Is this a normal behavior? Or the request to the WSDL should also include the User-Agent field? Please comment to determine if patch should be applied or not to include the field in the initial request
Re: [PHP-DEV] Uploading a patch fails...
2012/1/28 Ángel González keis...@gmail.com: On 28/01/12 03:05, Rasmus Lerdorf wrote: There is a 100k limit, but the error message you are getting indicates that you aren't actually hitting that limitation. The server config has a 2M limit, so you should be fitting well within that. I'm not sure how your 200k patch is hittig that file is empty condition in the code. You mean upload_max_filesize is 2M? What about post_max_size ? That could well lead to that condition. post_max_size = 8M -- Ferenc Kovács @Tyr43l - http://tyrael.hu -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Uploading a patch fails...
Okay... Pierre had recommended I upload the patches to that bug report when I first got started. I just finished getting the last of the hard stuff working tonight. The patch is pretty big (though the 200k may have had a lot of white-space changes). It may also be so big because that patch included updates to the Reflection extension as well as tests for just about everything, plenty of code there. Would it be best to break apart the code into sets of diffs, such as: - Reflection - Reflection Tests - Feature - Feature Tests Thanks, -Clint -Original Message- From: Ferenc Kovacs [mailto:tyr...@gmail.com] Sent: Saturday, January 28, 2012 4:00 PM To: Stas Malyshev Cc: Rasmus Lerdorf; Clint M Priest; internals@lists.php.net Subject: Re: [PHP-DEV] Uploading a patch fails... BTW, I would recommend using Wiki and RFC for tracking new features, especially of this magnitude. This is obviously not a bug, and not a small feature request either... the RFC is already in the wiki, AFAIR it is linked from the ticket also. https://wiki.php.net/rfc/propertygetsetsyntax https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented -- Ferenc Kovács @Tyr43l - http://tyrael.hu
