[PHP-DEV] Re: [PHP-CVS] com php-src: Fixed bug #61922 (ZTS build doesn't accept zend.script_encoding config): NEWS Zend/zend.c
Hi Laruence,
Thank you for sending this.
I'm not sure if the patch is completely correct.
With the patch all the threads share the single copy of
script_encoding_list and when one thread terminates it calls
compiler_globals_dtor() and frees the script_encoding_list. But other
threads still keep reference to it.
I think we have to duplicate script_encoding_list for each thread in the
same way as we do for CG(function_table).
Also I noticed a related issue. At zend.c compiler_globals_dtor()
CG(script_encoding_list) deallocated using free() and in
zend_multibyte.c zend_multibyte_set_script_encoding() using efree().
I suppose the second place has to be fixed.
I would appreciate if you could look into the problems.
Thanks. Dmitry.
On 05/03/2012 06:51 PM, Laruence wrote:
Hi, Dmitry:
you may want to review this, :)
thanks
On Thu, May 3, 2012 at 10:39 PM, Xinchen Huilarue...@php.net wrote:
Commit:72f19e9a8bcf5712b24fa333a26616eff19ac1ce
Author:Xinchen Huilarue...@php.net Thu, 3 May 2012 22:39:53
+0800
Parents: d74d88fbb9c29b1dd5ff05a54b72cf7c9250955c
Branches: PHP-5.4
Link:
http://git.php.net/?p=php-src.git;a=commitdiff;h=72f19e9a8bcf5712b24fa333a26616eff19ac1ce
Log:
Fixed bug #61922 (ZTS build doesn't accept zend.script_encoding config)
Bugs:
https://bugs.php.net/61922
Changed paths:
M NEWS
M Zend/zend.c
Diff:
diff --git a/NEWS b/NEWS
index 8796cf4..9ef6abf 100644
--- a/NEWS
+++ b/NEWS
@@ -10,6 +10,8 @@ PHP
NEWS
(Laruence)
- Core:
+ . Fixed bug #61922 (ZTS build doesn't accept zend.script_encoding config).
+(Laruence)
. Fixed missing bound check in iptcparse(). (chris at chiappa.net)
. Fixed bug #61827 (incorrect \e processing on Windows) (Anatoliy)
. Fixed bug #61761 ('Overriding' a private static method with a different
diff --git a/Zend/zend.c b/Zend/zend.c
index dd299f1..37a1a27 100644
--- a/Zend/zend.c
+++ b/Zend/zend.c
@@ -781,6 +781,8 @@ void zend_register_standard_ini_entries(TSRMLS_D) /* {{{ */
void zend_post_startup(TSRMLS_D) /* {{{ */
{
#ifdef ZTS
+ zend_encoding **script_encoding_list;
+
zend_compiler_globals *compiler_globals =
ts_resource(compiler_globals_id);
zend_executor_globals *executor_globals =
ts_resource(executor_globals_id);
@@ -795,7 +797,12 @@ void zend_post_startup(TSRMLS_D) /* {{{ */
zend_destroy_rsrc_list(EG(persistent_list) TSRMLS_CC);
free(compiler_globals-function_table);
free(compiler_globals-class_table);
- compiler_globals_ctor(compiler_globals, tsrm_ls);
+ if ((script_encoding_list = (zend_encoding
**)compiler_globals-script_encoding_list)) {
+ compiler_globals_ctor(compiler_globals, tsrm_ls);
+ compiler_globals-script_encoding_list = (const zend_encoding
**)script_encoding_list;
+ } else {
+ compiler_globals_ctor(compiler_globals, tsrm_ls);
+ }
free(EG(zend_constants));
executor_globals_ctor(executor_globals, tsrm_ls);
global_persistent_list =EG(persistent_list);
--
PHP CVS Mailing List (http://www.php.net/)
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] Enforcing final in traits
On Sat, May 5, 2012 at 1:38 AM, Stefan Marr p...@stefan-marr.de wrote: On 04 May 2012, at 21:46, Hannes Magnusson wrote: On Fri, May 4, 2012 at 8:30 PM, Scott MacVicar sc...@macvicar.net wrote: This caused a few bugs for us / confusion. The final keyword is accepted inside a trait but it the class also defines a method without the final keyword this takes precedence. The methods in the class always take precedency. However, the final keyword might just be something I overlooked. It sounds sensible that if the final is not explicitly removed during composition to treat it as what final was meant for and check it against the methods defined in the class body as well. Scott, could you elaborate a bit of the use case of final in a trait? Here is an example: http://stackoverflow.com/questions/7104957/building-a-singleton-trait-with-php-5-4 Not the best things to use traits for, but probably something people *will* try to do. Nikita -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] com php-src: Fixed bug #61922 (ZTS build doesn't accept zend.script_encoding config): NEWS Zend/zend.c
On Sat, May 5, 2012 at 2:36 PM, Dmitry Stogov dmi...@zend.com wrote:
Hi Laruence,
Thank you for sending this.
I'm not sure if the patch is completely correct.
With the patch all the threads share the single copy of script_encoding_list
and when one thread terminates it calls compiler_globals_dtor() and frees
the script_encoding_list. But other threads still keep reference to it.
I think we have to duplicate script_encoding_list for each thread in the
same way as we do for CG(function_table).
right, thanks
Also I noticed a related issue. At zend.c compiler_globals_dtor()
CG(script_encoding_list) deallocated using free() and in zend_multibyte.c
zend_multibyte_set_script_encoding() using efree().
I suppose the second place has to be fixed.
I would appreciate if you could look into the problems.
okey, I will, thanks :)
Thanks. Dmitry.
On 05/03/2012 06:51 PM, Laruence wrote:
Hi, Dmitry:
you may want to review this, :)
thanks
On Thu, May 3, 2012 at 10:39 PM, Xinchen Huilarue...@php.net wrote:
Commit: 72f19e9a8bcf5712b24fa333a26616eff19ac1ce
Author: Xinchen Huilarue...@php.net Thu, 3 May 2012
22:39:53 +0800
Parents: d74d88fbb9c29b1dd5ff05a54b72cf7c9250955c
Branches: PHP-5.4
Link:
http://git.php.net/?p=php-src.git;a=commitdiff;h=72f19e9a8bcf5712b24fa333a26616eff19ac1ce
Log:
Fixed bug #61922 (ZTS build doesn't accept zend.script_encoding config)
Bugs:
https://bugs.php.net/61922
Changed paths:
M NEWS
M Zend/zend.c
Diff:
diff --git a/NEWS b/NEWS
index 8796cf4..9ef6abf 100644
--- a/NEWS
+++ b/NEWS
@@ -10,6 +10,8 @@ PHP
NEWS
(Laruence)
- Core:
+ . Fixed bug #61922 (ZTS build doesn't accept zend.script_encoding
config).
+ (Laruence)
. Fixed missing bound check in iptcparse(). (chris at chiappa.net)
. Fixed bug #61827 (incorrect \e processing on Windows) (Anatoliy)
. Fixed bug #61761 ('Overriding' a private static method with a
different
diff --git a/Zend/zend.c b/Zend/zend.c
index dd299f1..37a1a27 100644
--- a/Zend/zend.c
+++ b/Zend/zend.c
@@ -781,6 +781,8 @@ void zend_register_standard_ini_entries(TSRMLS_D) /*
{{{ */
void zend_post_startup(TSRMLS_D) /* {{{ */
{
#ifdef ZTS
+ zend_encoding **script_encoding_list;
+
zend_compiler_globals *compiler_globals =
ts_resource(compiler_globals_id);
zend_executor_globals *executor_globals =
ts_resource(executor_globals_id);
@@ -795,7 +797,12 @@ void zend_post_startup(TSRMLS_D) /* {{{ */
zend_destroy_rsrc_list(EG(persistent_list) TSRMLS_CC);
free(compiler_globals-function_table);
free(compiler_globals-class_table);
- compiler_globals_ctor(compiler_globals, tsrm_ls);
+ if ((script_encoding_list = (zend_encoding
**)compiler_globals-script_encoding_list)) {
+ compiler_globals_ctor(compiler_globals, tsrm_ls);
+ compiler_globals-script_encoding_list = (const
zend_encoding **)script_encoding_list;
+ } else {
+ compiler_globals_ctor(compiler_globals, tsrm_ls);
+ }
free(EG(zend_constants));
executor_globals_ctor(executor_globals, tsrm_ls);
global_persistent_list =EG(persistent_list);
--
PHP CVS Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--
Laruence Xinchen Hui
http://www.laruence.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Allow non-variable arguments to empty() and isset()
On Fri, May 4, 2012 2:10 pm, Kris Craig wrote: On Fri, May 4, 2012 at 11:48 AM, Richard Lynch c...@l-i-e.com wrote: On Wed, May 2, 2012 4:43 am, Pierre Joye wrote: empty() on the other hand, tests if something is empty, and only if it is empty. The result of an expression can be empty. an expression can also have a value of null. And NULL is empty. No issue here. Expressions can also return , 0, 0.0, 0, array() You really think those should all be empty? Unless I'm missing something here, aren't all those things already considered to be empty?? Here's what the PHP man page for empty() says: The following things are considered to be empty: - ** (an empty string) - *0* (0 as an integer) - *0.0* (0 as a float) - *0* (0 as a string) - *NULL* - *FALSE* - *array()* (an empty array) - *var $var;* (a variable declared, but without a value in a class) I am suggesting that some of those wouldn't make so much sense being empty in an expression. empty(2.0 - 1.9); Might not be 0.0, but that's not the point. For some not-empty values added or subtracted, more or less at the whims of digital float behave would or wouldn't be empty. Furthermore, empty on 0 was originally designed user input via GET/POST so that an option0/option would be empty() -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Fixing bug #18556 (was: Complete case-sensitivity in PHP)
On 5/5/2012 12:22 AM, Galen Wright-Watson wrote: That also ran without error for me. I'm not sure how to account for the different behavior. Here are the details of the system that I'm using: $ uname -a Linux n10 3.2.6mtv10 #1 SMP Wed Mar 14 06:22:06 PDT 2012 x86_64 GNU/Linux $ php -v PHP 5.2.17 with Suhosin-Patch 0.9.7 (cli) (built: May 3 2012 12:16:32) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2010 Zend Technologies with Zend Optimizer v3.3.9, Copyright (c) 1998-2009, by Zend Technologies with Suhosin v0.9.32.1, Copyright (c) 2007-2010, by SektionEins GmbH I've been experimenting with bare-bones PHP I've built from pristine sources so far. Don't you think you should do the same, in dealing with such a bug? Here's the top portion of my 'php -i' output: ~/proj$ php-5.2.17/sapi/cli/php -i|head -28 phpinfo() PHP Version = 5.2.17 System = Linux trvuntu 2.6.32-41-generic #88-Ubuntu SMP Thu Mar 29 13:08:43 UTC 2012 i686 Build Date = May 4 2012 20:03:30 Configure Command = './configure' '--disable-all' '--enable-cli' '--enable-vld' Server API = Command Line Interface Virtual Directory Support = disabled Configuration File (php.ini) Path = /usr/local/lib Loaded Configuration File = (none) Scan this dir for additional .ini files = (none) additional .ini files parsed = (none) PHP API = 20041225 PHP Extension = 20060613 Zend Extension = 220060519 Debug Build = no Thread Safety = disabled Zend Memory Manager = enabled IPv6 Support = enabled Registered PHP Streams = php, file, data, http, ftp Registered Stream Socket Transports = tcp, udp, unix, udg Registered Stream Filters = string.rot13, string.toupper, string.tolower, string.strip_tags, convert.*, consumed This program makes use of the Zend Scripting Language Engine: Zend Engine v2.2.0, Copyright (c) 1998-2010 Zend Technologies -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP extension versions
I'm terribly sorry, but I managed to delete the original while running through the thread to be sure I didn't duplicate comments, and my mailer won't let me respond to a deleted message. So this will appear as a new thread. #1 A standard for non-core extension version fields is a great idea. But if all the core ones are PHP_VERSION, you might as well suppress it completely, as there's not much point in checking it. #2 The curl version is in an Information field. The original poster may wish to maintain a list of which extensions have version information in which fields for now. #3 It wasn't 100% clear when I read it, but I presume the non-core extensions wouldn't have all their versions set to PHP_VERSION. That would make the whole thing completely useless... -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: internals Digest 18 Apr 2012 20:34:27 -0000 Issue 2671
On Wed, April 18, 2012 9:42 pm, Rasmus Schultz wrote: On 04/10/2012 06:20 PM, Adir Kuhn wrote: PHP Gotchas, how they came to be, and why we can't simply fix them can't or won't? It seems that the requirement for backward compatibility, as with most software, stands in the way of any substantial leaps, and makes it impossible to do away with outdated cruft. As a result, PHP is dragging around a lot of baggage - both the language itself and the libraries. Hey, here's a crazy thought: ?php6 Now you don't have to be backward compatible - the bytecode needs to remain compatible with bytecode generated by standard ?php tags of course, but you're free to change/improve/deprecate/extend the syntax, update inconsistent APIs, etc. I know this is no small thing, heh. I'm sure there's some technical reason this isn't even feasible or possible... I just figured I'd bring it up anyway, it's always fun to see your reactions to such radical ideas - bring on the flames! ;-) Using the Duck Rule, this seems the same as a php.ini switch for core PHP. We all know how that one worked out... -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] com php-src: Fixed bug #61922 (ZTS build doesn't accept zend.script_encoding config): NEWS Zend/zend.c
Hi Dmitry:
On Sat, May 5, 2012 at 6:38 PM, Laruence larue...@php.net wrote:
On Sat, May 5, 2012 at 2:36 PM, Dmitry Stogov dmi...@zend.com wrote:
Hi Laruence,
Thank you for sending this.
I'm not sure if the patch is completely correct.
With the patch all the threads share the single copy of script_encoding_list
and when one thread terminates it calls compiler_globals_dtor() and frees
the script_encoding_list. But other threads still keep reference to it.
I think we have to duplicate script_encoding_list for each thread in the
same way as we do for CG(function_table).
after a further exam, this is right, there is a mechanism for new
thread re-configure inis(zend_ini_refresh_caches). then new thread
will have a copy.
right, thanks
Also I noticed a related issue. At zend.c compiler_globals_dtor()
CG(script_encoding_list) deallocated using free() and in zend_multibyte.c
zend_multibyte_set_script_encoding() using efree().
I suppose the second place has to be fixed.
I would appreciate if you could look into the problems.
and this should use free, I will fix it . however for now it's dead
codes, so no bug feedback. :)
thanks
okey, I will, thanks :)
Thanks. Dmitry.
On 05/03/2012 06:51 PM, Laruence wrote:
Hi, Dmitry:
you may want to review this, :)
thanks
On Thu, May 3, 2012 at 10:39 PM, Xinchen Huilarue...@php.net wrote:
Commit: 72f19e9a8bcf5712b24fa333a26616eff19ac1ce
Author: Xinchen Huilarue...@php.net Thu, 3 May 2012
22:39:53 +0800
Parents: d74d88fbb9c29b1dd5ff05a54b72cf7c9250955c
Branches: PHP-5.4
Link:
http://git.php.net/?p=php-src.git;a=commitdiff;h=72f19e9a8bcf5712b24fa333a26616eff19ac1ce
Log:
Fixed bug #61922 (ZTS build doesn't accept zend.script_encoding config)
Bugs:
https://bugs.php.net/61922
Changed paths:
M NEWS
M Zend/zend.c
Diff:
diff --git a/NEWS b/NEWS
index 8796cf4..9ef6abf 100644
--- a/NEWS
+++ b/NEWS
@@ -10,6 +10,8 @@ PHP
NEWS
(Laruence)
- Core:
+ . Fixed bug #61922 (ZTS build doesn't accept zend.script_encoding
config).
+ (Laruence)
. Fixed missing bound check in iptcparse(). (chris at chiappa.net)
. Fixed bug #61827 (incorrect \e processing on Windows) (Anatoliy)
. Fixed bug #61761 ('Overriding' a private static method with a
different
diff --git a/Zend/zend.c b/Zend/zend.c
index dd299f1..37a1a27 100644
--- a/Zend/zend.c
+++ b/Zend/zend.c
@@ -781,6 +781,8 @@ void zend_register_standard_ini_entries(TSRMLS_D) /*
{{{ */
void zend_post_startup(TSRMLS_D) /* {{{ */
{
#ifdef ZTS
+ zend_encoding **script_encoding_list;
+
zend_compiler_globals *compiler_globals =
ts_resource(compiler_globals_id);
zend_executor_globals *executor_globals =
ts_resource(executor_globals_id);
@@ -795,7 +797,12 @@ void zend_post_startup(TSRMLS_D) /* {{{ */
zend_destroy_rsrc_list(EG(persistent_list) TSRMLS_CC);
free(compiler_globals-function_table);
free(compiler_globals-class_table);
- compiler_globals_ctor(compiler_globals, tsrm_ls);
+ if ((script_encoding_list = (zend_encoding
**)compiler_globals-script_encoding_list)) {
+ compiler_globals_ctor(compiler_globals, tsrm_ls);
+ compiler_globals-script_encoding_list = (const
zend_encoding **)script_encoding_list;
+ } else {
+ compiler_globals_ctor(compiler_globals, tsrm_ls);
+ }
free(EG(zend_constants));
executor_globals_ctor(executor_globals, tsrm_ls);
global_persistent_list =EG(persistent_list);
--
PHP CVS Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--
Laruence Xinchen Hui
http://www.laruence.com/
--
Laruence Xinchen Hui
http://www.laruence.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: Trouble with zend_language_parser.y
Hi Clint, On Wed, May 2, 2012 at 3:23 PM, Clint Priest cpri...@zerocue.com wrote: Anyone have any help with this? hard to say like this with this partial patch, do you have some git branch I can pull from to reproduce and analyze this? Alternatively, the complete an up-to-date patch? Best Regards, -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Trouble with zend_language_parser.y
Hi, 2012/4/26 Clint Priest cpri...@zerocue.com: I'm having some trouble setting up the re2c to allow the isset/unset. Here are the definitions, I've added the two T_ISSET statements: accessors: accessor_function accessor_function accessor_function accessor_function | accessor_function accessor_function accessor_function | accessor_function accessor_function | accessor_function | /* Empty */ ; This rule is weird too, do you want a limited number of accessor? -- Regards, Felipe Pena
Re: [PHP-DEV] Allow non-variable arguments to empty()
On Thu, April 12, 2012 6:05 pm, Johannes Schlüter wrote:
On Wed, 2012-04-11 at 00:53 +0200, Nikita Popov wrote:
Currently the empty() language construct only works on variables.
You
can write if (empty($array)) but not empty if
(empty(getSomeArray()).
I've mentioned this thought off-list already but let's discuss it
officially:
A fear I have is that this makes empty more looking like a function,
while not being one. Right now one notices quite quickly that it is
something else. Things like $check = $condition ? empty : isset;
$check($bar); trigger an even more confusing error (Call to undefined
function)
I'm not sure whether that's a strong argument, but I guess it's good
enough to be noted :-)
If one doesn't know isset/empty aren't functions, one doesn't
understand their purpose nor how variables are used/scoped.
If one doesn't know these things, one should learn. Quickly.
Call to undefined function is exactly correct.
$a = 5;
$b = 3;
$foo = 'if';
$foo ($a == $b){
echo Nope.;
}
While it might be as nifty as runkit to do this, it should not be
encouraged. Or even allowed.
--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Allow non-variable arguments to empty()
On Tue, April 10, 2012 5:53 pm, Nikita Popov wrote: Another reason is that currently you get a very obscure error message if you try to use empty() on a function return value: Can't use function return value in write context. Aha. Where did I try to write to the return value?! On the line number indicated in the message :-) More seriously, if the guts of PHP can easily detect when you are not really write context versus this, just fix the error message to something more meaningful. -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Optional PHP tags by php.ini and CLI options (Ver. 1.4)
On Wed, April 11, 2012 5:14 pm, Yasuo Ohgaki wrote: I think my RFC confused people on this list due to improper descriptions and too much information. Sorry for the confusion. I revised the RFC so that most important points can be understood at a glance. https://wiki.php.net/rfc/nophptags We all know there are a LOT of bad scripts out there. A *LOT* of bad scripts. With major security holes in them. I do not see your average PHP scripter changing that behavior: It's just so easy to write a PHP script, which is why it's so popular. Now, you are going to open up all the inexperienced scripters to code exposure when they start using this cool new feature of being lazy and not typing that silly ?php tag. And that code being exposed will have major security holes in it. This is just not a good idea... Instead of random bots attacking random URLs hoping to hit pay dirt for an SQL injection, you will have bots that: Use google to find stuff that looks like raw PHP code. Scape page to look for mysql.*$_POST Attack site. Unless I'm really missing something here, you put a few million people's code at risk, for a feature that has dubious value in the first place. -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Fixing bug #18556 (was: Complete case-sensitivity in PHP)
On 05/04/2012 11:22 PM, Galen Wright-Watson wrote:
On Fri, May 4, 2012 at 7:01 AM, C.Koycan5...@gmail.com wrote:
On 5/2/2012 10:03 PM, Galen Wright-Watson wrote:
On Wed, May 2, 2012 at 5:23 AM, C.Koycan5...@gmail.com wrote:
On 5/1/2012 9:11 PM, Galen Wright-Watson wrote:
On Thu, Apr 26, 2012 at 3:45 AM, C.Koycan5...@gmail.comwrote:
As of 5.3.0 this bug does not exist for function names. Only classes
and
interfaces.
Turns out, if you cause a function to be called dynamically by (e.g.)
using
a variable function, the bug will surface.
?php
setlocale(LC_CTYPE, 'tr_TR');
function IJK() {}
# succeeds
IJK();
If literal function call precedes the function definition, that would
fail
too in 5.2.17, but not in 5.3.0.
What has changed in this regard 5.2-5.3 ?
Do you mean something like the following?
?php
setlocale(LC_CTYPE, 'tr_TR');
IJK();
setlocale(LC_CTYPE, 'en_US');
function IJK() {echo __FUNCTION__, \n;}
I couldn't get it to generate an error under PHP 5.2.17. What am I
missing?
Try this with 5.2.17:
?php
setlocale(LC_CTYPE, 'tr_TR');
IJK();
function IJK() {}
That also ran without error for me. I'm not sure how to account for the
different behavior. Here are the details of the system that I'm using:
$ uname -a
Linux n10 3.2.6mtv10 #1 SMP Wed Mar 14 06:22:06 PDT 2012 x86_64 GNU/Linux
$ php -v
PHP 5.2.17 with Suhosin-Patch 0.9.7 (cli) (built: May 3 2012 12:16:32)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2010 Zend Technologies
with Zend Optimizer v3.3.9, Copyright (c) 1998-2009, by Zend
Technologies
with Suhosin v0.9.32.1, Copyright (c) 2007-2010, by SektionEins GmbH
Try to var_dump the setLocale and see if it return the specified locale
or just 'false'. If false try the following:
setlocale(LC_ALL, 'tr_TR.UTF-8');
I had the same issue.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [off] PHP: a fractal of bad design
On Tue, April 10, 2012 1:27 pm, Stas Malyshev wrote:
Hi!
Scroll down a bit; he gets into valid points about the == operator,
for instance. It's not a useless post. He does cite too many things
that he has to follow up himself by saying this was fixed in PHP
5.x.y. If it was fixed, why is it on your laundry list still?
What exactly valid points? == is a converting operator, === is a
strict
operator. OK, in his favorite language it is not. Where exactly the
valid point is? Author goes at great lengths to refuse to make even a
slight mental effort to understand how it works (really, it's not that
hard) and then complains it's useless. Well, a lot of things would
be
useless if you don't want to know how to use them.
He has a few valid points in the part I read before I got bored...
$a = 123ABF453...; //a password
$b = 123DFEABC...; //another one
if ($a == $b){
//you're in.
}
Yes, one should have validated the input...
But you don't have to be THAT naive to think that the hashed value of
an SQL injection attack just isn't going to work, so it's safe...
I'll bet I have some of these in my (recent) code, for that matter.
On the other hand, if you accept type juggling, you have to expect the
other cases he has for == being a bit strange.
--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] JPEG Upload
On Tue, April 10, 2012 1:13 pm, John Crenshaw wrote: In most systems you can upload *anything* with a .jpg extension and the app will take it, so you can still include the file People don't use imagecreatefromjpeg() to be sure it isn't some ware or executable or PHP script disguised as a JPEG?! That's just crazy. And inexcusable in a framework. Somebody might be able to craft a JPEG that validates and still manages to somehow parse some PHP in the middle... Probably using JPEG comments so it's easier. But on should at least you'd have some kind of validation on user input! -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Disabling PHP tags by php.ini and CLI options
On Wed, April 11, 2012 12:25 am, Stas Malyshev wrote:
Hi!
I'm sure you have seen the same code in JSON hijack countermeasure.
while(1){}
I think you misunderstood what I means. What I meant is you can inject
code without ? the same way you can inject code with ?, so where's
the
improvement?
kill() function would be just an example of code being injected by
hostile third party (intent on killing your server, presumably). If I
can inject it with ?, what prevents me from injecting without ? ?
Actually, it makes it worse.
I can search for '?php' (no short open tags) or '?=' and reject
without the new feature.
Without the new feature, no easy way to detect it contains PHP code.
--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Education
[soapbox] Several people in at least one thread (I can't remember) have stated: Education won't work. I must take objection to that. Not too long ago, a large number of people on this very list agreed that SQL Injection was a Big Problem, and if they all blogged about it, awareness would help. And so it was. Did it stop SQL injection completely? No. Did it make a serious dent? YES! Never underestimate the power of injection. Nor your collective power here to make a concerted effort to educate with tremendous succes. [/soapbox] -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] JPEG Upload
On Sat, May 5, 2012 at 6:32 PM, Richard Lynch c...@l-i-e.com wrote: On Tue, April 10, 2012 1:13 pm, John Crenshaw wrote: In most systems you can upload *anything* with a .jpg extension and the app will take it, so you can still include the file People don't use imagecreatefromjpeg() to be sure it isn't some ware or executable or PHP script disguised as a JPEG?! That's just crazy. And inexcusable in a framework. Somebody might be able to craft a JPEG that validates and still manages to somehow parse some PHP in the middle... Probably using JPEG comments so it's easier. yeah, and injecting php code through the jpeg comments isn't new also, see http://ha.ckers.org/blog/20070604/passing-malicious-php-through-getimagesize/ but I bet I could find even older posts discussing the topic. so imo the correct remedy for this situation is to prevent your uploaded files to be executed at the first place, instead of trying to write an error-prone method to detect malicious content inside your uploaded media files. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] release process with git
On Tue, April 17, 2012 3:34 am, Martin Jansen wrote: On 17.04.12 10:24, Bas van Beek wrote: Sounds like facilitating wrong security protocols to me. In this 365/24/7 environment, sysadmins should be willing and able to patch, fix and secure systems at any time. Weekend should be no excuse. Willing to? Yes. Happy about it? No. Deciding PHP is a PITA because it keeps making them work on weekends? Bad Idea. -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] JPEG Upload
On Sat, May 5, 2012 12:29 pm, Ferenc Kovacs wrote: On Sat, May 5, 2012 at 6:32 PM, Richard Lynch c...@l-i-e.com wrote: On Tue, April 10, 2012 1:13 pm, John Crenshaw wrote: In most systems you can upload *anything* with a .jpg extension and the app will take it, so you can still include the file People don't use imagecreatefromjpeg() to be sure it isn't some ware or executable or PHP script disguised as a JPEG?! That's just crazy. And inexcusable in a framework. Somebody might be able to craft a JPEG that validates and still manages to somehow parse some PHP in the middle... Probably using JPEG comments so it's easier. yeah, and injecting php code through the jpeg comments isn't new also, see http://ha.ckers.org/blog/20070604/passing-malicious-php-through-getimagesize/ but I bet I could find even older posts discussing the topic. so imo the correct remedy for this situation is to prevent your uploaded files to be executed at the first place, instead of trying to write an error-prone method to detect malicious content inside your uploaded media files. getImageSize is not better than file Info... If the whole thing parses as an image with imagecreatefromjpeg() I should think that's a bit tougher to create a hack that works. Then one can strip off the exif info with the comments, I believe. And, yes, ideally one would keep images in a totally separate directory not even in the webtree... Which I do, but some folks can bear the cost of passing the image through PHP. -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Fixing bug #18556 (was: Complete case-sensitivity in PHP)
On 5/5/2012 7:01 PM, Wim Wisselink wrote:
Try to var_dump the setLocale and see if it return the specified locale
or just 'false'.
I thought he was way past that control. Anyway, a simple test should
suffice:
setlocale(LC_CTYPE, 'tr_TR') or exit('setlocale failed\n');
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] JPEG Upload
On Sat, May 5, 2012 at 7:50 PM, Richard Lynch c...@l-i-e.com wrote: On Sat, May 5, 2012 12:29 pm, Ferenc Kovacs wrote: On Sat, May 5, 2012 at 6:32 PM, Richard Lynch c...@l-i-e.com wrote: On Tue, April 10, 2012 1:13 pm, John Crenshaw wrote: In most systems you can upload *anything* with a .jpg extension and the app will take it, so you can still include the file People don't use imagecreatefromjpeg() to be sure it isn't some ware or executable or PHP script disguised as a JPEG?! That's just crazy. And inexcusable in a framework. Somebody might be able to craft a JPEG that validates and still manages to somehow parse some PHP in the middle... Probably using JPEG comments so it's easier. yeah, and injecting php code through the jpeg comments isn't new also, see http://ha.ckers.org/blog/20070604/passing-malicious-php-through-getimagesize/ but I bet I could find even older posts discussing the topic. so imo the correct remedy for this situation is to prevent your uploaded files to be executed at the first place, instead of trying to write an error-prone method to detect malicious content inside your uploaded media files. getImageSize is not better than file Info... I didn't talked about at all. If the whole thing parses as an image with imagecreatefromjpeg() I should think that's a bit tougher to create a hack that works. maybe, but would you bet your site's security on it? Then one can strip off the exif info with the comments, I believe. yeah, you just have to totally understand all of your supported media formats just to make sure that there is no other way to inject malicious php code. And, yes, ideally one would keep images in a totally separate directory not even in the webtree... Which I do, but some folks can bear the cost of passing the image through PHP. yeah, for bigger sites, you would already serve the static assets through some other http server (something lightweight more suited for serving static files, like nginx, cherokee, lighty, etc.) on a separate domain, on a separate box. even if you serve those on the same vhost, you could still do engine off ( http://www.php.net/manual/en/apache.configuration.php#ini.engine) for that directory where you keep your uploaded files, which would prevent the direct execution of those files. one could still execute those malicious files if you have a Local File Inclusion vulnerability but if you do, that's game over for most cases already. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] JPEG Upload
This whole business of bending over backwards to prevent injection of php when apache is misconfigured just encourages apache misconfiguration IMHO. Smart people are protecting you, you don't have to do these things right, don't worry about it! Sent from my iPhone On May 5, 2012, at 1:50 PM, Richard Lynch c...@l-i-e.com wrote: On Sat, May 5, 2012 12:29 pm, Ferenc Kovacs wrote: On Sat, May 5, 2012 at 6:32 PM, Richard Lynch c...@l-i-e.com wrote: On Tue, April 10, 2012 1:13 pm, John Crenshaw wrote: In most systems you can upload *anything* with a .jpg extension and the app will take it, so you can still include the file People don't use imagecreatefromjpeg() to be sure it isn't some ware or executable or PHP script disguised as a JPEG?! That's just crazy. And inexcusable in a framework. Somebody might be able to craft a JPEG that validates and still manages to somehow parse some PHP in the middle... Probably using JPEG comments so it's easier. yeah, and injecting php code through the jpeg comments isn't new also, see http://ha.ckers.org/blog/20070604/passing-malicious-php-through-getimagesize/ but I bet I could find even older posts discussing the topic. so imo the correct remedy for this situation is to prevent your uploaded files to be executed at the first place, instead of trying to write an error-prone method to detect malicious content inside your uploaded media files. getImageSize is not better than file Info... If the whole thing parses as an image with imagecreatefromjpeg() I should think that's a bit tougher to create a hack that works. Then one can strip off the exif info with the comments, I believe. And, yes, ideally one would keep images in a totally separate directory not even in the webtree... Which I do, but some folks can bear the cost of passing the image through PHP. -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- 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] JPEG Upload
Then one can strip off the exif info with the comments, I believe. This presupposes that your users don't expect embedded metadata to be preserved when people redownload the images. Not only do photo professionals/hobbyists expect you to keep the metadata, you also should leave it in for reasons of legality. Hosting a bunch of stripped images can make you look really bad. We only strip metadata that is known to cause browser display problems (mostly old IE6/Adobe comment bugs). Bottom line is you have to make sure PHP never parses the files. -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] JPEG Upload
On 05/05/12 20:08, Sanford Whiteman wrote: This presupposes that your users don't expect embedded metadata to be preserved when people redownload the images. Not only do photo professionals/hobbyists expect you to keep the metadata, you also should leave it in for reasons of legality. Hosting a bunch of stripped images can make you look really bad. We only strip metadata that is known to cause browser display problems (mostly old IE6/Adobe comment bugs). Bottom line is you have to make sure PHP never parses the files. -- S. Moreover, that still doesn't protect you, as it would be possible to make a valid image where the payload happened in the image data. I haven't tried to create such malicious image, but I have found legit images that tripped bad-image-detection heuristics looking for a 4-byte magic. Image contents are a bunch of random bytes, but 'DROP TABLE Students;' is binary data, too. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] JPEG Upload
Moreover, that still doesn't protect you, as it would be possible to make a valid image where the payload happened in the image data... Agreed. But sanitizing input by silently removing blocks of data your users rightfully expect to be preserved? That's egregious, even if it worked. (Like many such discussions, I almost can't believe we're having this one... I mean, executing images is just not normal whether or not you can bear the (performance) cost. Who is doing this on purpose?) -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Fixing bug #18556 (was: Complete case-sensitivity in PHP)
On Sat, May 5, 2012 at 5:31 AM, C.Koy can5...@gmail.com wrote:
I've been experimenting with bare-bones PHP I've built from pristine
sources so far. Don't you think you should do the same, in dealing with
such a bug?
My personal system is a BSD derivative; the Turkish locales on these use
latin rather than Turkish case conversion (and installing a proper Turkish
locale is a mess), so I've been testing on another system. I've been
hesitant to use its resources too heavily for professional reasons. Running
a small PHP script is one thing; though time and space required for a PHP
build isn't large on modern systems, I can't justify doing so since it's
not directly related to site operations.
On Sat, May 5, 2012 at 8:59 AM, Wim Wisselink w...@powerassist.nl wrote:
Try to var_dump the setLocale and see if it return the specified locale or
just 'false'. If false try the following:
setlocale(LC_ALL, 'tr_TR.UTF-8');
I had previously tested the locale by using setlower('I'), as it tests
both that the locale exists and uses Turkish-langage case conversion. The
systems where I tested C.Koy's script passed the setlower test. Turned
out to be the Zend optimizer that prevented the error. With it not loaded,
the example script failed with a Fatal error: Call to undefined function
IJK() error message.
Here's a breakdown:
In both PHP 5.2 and 5.3, calling a function before defining it results in a
dynamic call (INIT_FCALL_BY_NAME+DO_FCALL_BY_NAME). Here's the PHP 5.2 dump
of C.Koy's example:
line # * op fetch ext return
operands
-
2 0 FETCH_CONSTANT ~0
'LC_CTYPE'
1 SEND_VAL
~0
2 SEND_VAL
'tr_TR'
3 DO_FCALL 2
'setlocale'
3 4 INIT_FCALL_BY_NAME
'IJK'
5 DO_FCALL_BY_NAME 0
4 6 NOP
5 7 RETURN 1
8*ZEND_HANDLE_EXCEPTION
Here's the 5.3 dump:
line # * op fetch ext return
operands
-
2 0 EXT_STMT
1 EXT_FCALL_BEGIN
2 SEND_VAL 2
3 SEND_VAL
'tr_TR'
4 DO_FCALL 2
'setlocale'
5 EXT_FCALL_END
3 6 EXT_STMT
7 INIT_FCALL_BY_NAME
'ijk', 'IJK'
8 EXT_FCALL_BEGIN
9 DO_FCALL_BY_NAME 0
10 EXT_FCALL_END
411 EXT_STMT
12 NOP
513 RETURN 1
From line 7 in the 5.3 dump, we see 5.3 converts the function name to
lowercase during compilation, but 5.2 doesn't. Examining the source
confirms this: you can see the lowercase conversion in 5.3's
zend_do_begin_dynamic_function_call on lines 1659 (for namespaced calls)
and 1683 (for non-namespaced calls) of zend_compile.c (
http://svn.php.net/viewvc/php/php-src/branches/PHP_5_3_10/Zend/zend_compile.c?revision=323023view=markup#l1683),
while there's no such conversion in the same function in 5.2 (
http://svn.php.net/viewvc/php/php-src/branches/PHP_5_2/Zend/zend_compile.c?view=markuppathrev=302150#l1450
).
5.3 only performs case conversion if the function name is a CONST
expression, which is why defining the function after calling it works but
calling a function with a variable name breaks. Correspondingly, the
ZEND_INIT_FCALL_BY_NAME_SPEC_*_HANDLER (in zend_vm_execute.h) uses the
first operand (which is already lowercased), while the other
INIT_FCALL_BY_NAME opcode handlers (ZEND_INIT_FCALL_BY_NAME_SPEC_*_HANDLER)
use the second, non-lowercased operand.
The 5.2 INIT_FCALL_BY_NAME opcode handlers only ever use the second,
un-lowercased operand.
So, what does this mean for fixing the bug? Not so much when the function
or class is stored in a variable, since these can't be converted to
lowercase at compile time without converting all variables, which is too
wasteful of both time and space (as both the unconverted and converted
strings would need to be stored). For object instantiation,
zend_do_begin_new_object gets the class name ultimately from the
namespace_name rule. zend_do_begin_new_object could then take the resulting
znode and create a second, lowercased copy, storing it as the second
operand. ZEND_NEW_SPEC_HANDLER would then be altered to use the second
operand (if not UNUSED) to instantiate the object. This certainly seems a
valid alternative to a lowercasing version of the namespace_name rule; it's
not as far reaching, which may be good (in that it has less impact) and bad
(in that there may be
Re: [PHP-DEV] JPEG Upload
On Sat, May 5, 2012 1:52 pm, Ángel González wrote: I never said it was an iron-clad technique. Only that it would be harder to craft such an image. If your TOU that meta-data gets stripped, so be it. Or find a way to have (some of) your users have some level of trust. To: Tom (?) One doesn't always control one's apache config. Shared hosting, corporate environment with an inexperienced sysadmin, etc. -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] JPEG Upload
I dealt with jpegs with injected metadata quite a bit at a previous employer. In the end we ended up confirming the file was a proper image with the filetype functions, then stripping the metadata using some command line tools, and finally using a blacklist for key strings (like ?php) that could show up in the file. paul -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] catching exception using a variable passed by reference
Hi,
I stumbled upon this code while working with a variable passed by
reference, I was wondering if someone could provide some feedback before
raising a ticket, just in case PHP (5.3.6) is doing what it's supposed to
do.
In the code below I would expect catch to change the variable as
an assignment would do, but that doesn't happen.
function foo($exception)
{
try {
throw new Exception('foo error');
} catch (Exception $exception) {
var_dump(gettype($exception));
echo $exception-getMessage() . \n;
}
}
foo($error);
var_dump(gettype($error));
Expected:
string(6) object
foo error
string(6) object
Current result:
string(6) object
foo error
string(4) NULL
It looks like catch is creating a completely new variable in the scope,
also removing the existing one from it.
I appreciate this is an edge case, if not a bug is it worth adding it to
http://php.net/manual/en/language.exceptions.php or somewhere under
http://www.php.net/manual/en/language.references.php ?
Thank you!
Re: [PHP-DEV] catching exception using a variable passed by reference
On Sun, May 6, 2012 at 8:40 AM, Devis Lucato de...@lucato.it wrote:
Hi,
I stumbled upon this code while working with a variable passed by
reference, I was wondering if someone could provide some feedback before
raising a ticket, just in case PHP (5.3.6) is doing what it's supposed to
do.
In the code below I would expect catch to change the variable as
an assignment would do, but that doesn't happen.
function foo($exception)
{
try {
throw new Exception('foo error');
} catch (Exception $exception) {
var_dump(gettype($exception));
echo $exception-getMessage() . \n;
}
}
foo($error);
var_dump(gettype($error));
Expected:
string(6) object
foo error
string(6) object
Current result:
string(6) object
foo error
string(4) NULL
It looks like catch is creating a completely new variable in the scope,
also removing the existing one from it.
Hi,
could you file a bug at bugs.php.net? :)
thanks
I appreciate this is an edge case, if not a bug is it worth adding it to
http://php.net/manual/en/language.exceptions.php or somewhere under
http://www.php.net/manual/en/language.references.php ?
Thank you!
--
Laruence Xinchen Hui
http://www.laruence.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] catching exception using a variable passed by reference
On Sun, May 6, 2012 at 11:47 AM, Laruence larue...@php.net wrote:
On Sun, May 6, 2012 at 8:40 AM, Devis Lucato de...@lucato.it wrote:
Hi,
I stumbled upon this code while working with a variable passed by
reference, I was wondering if someone could provide some feedback before
raising a ticket, just in case PHP (5.3.6) is doing what it's supposed to
do.
In the code below I would expect catch to change the variable as
an assignment would do, but that doesn't happen.
function foo($exception)
{
try {
throw new Exception('foo error');
} catch (Exception $exception) {
var_dump(gettype($exception));
echo $exception-getMessage() . \n;
}
}
foo($error);
var_dump(gettype($error));
Expected:
string(6) object
foo error
string(6) object
Current result:
string(6) object
foo error
string(4) NULL
It looks like catch is creating a completely new variable in the scope,
also removing the existing one from it.
Hi:
after a deep look, I think it's not a bug.
the exception in the catch block is only a local var of that block.
I think you should change you codes like following to accomplish
your requirement:
function foo($exception)
{
try {
throw new Exception('foo error');
} catch (Exception $e) {
var_dump(gettype($e));
$exception = $e;
echo $e-getMessage() . \n;
}
}
foo($error);
var_dump(gettype($error));
thanks
Hi,
could you file a bug at bugs.php.net? :)
thanks
I appreciate this is an edge case, if not a bug is it worth adding it to
http://php.net/manual/en/language.exceptions.php or somewhere under
http://www.php.net/manual/en/language.references.php ?
Thank you!
--
Laruence Xinchen Hui
http://www.laruence.com/
--
Laruence Xinchen Hui
http://www.laruence.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] JPEG Upload
Or find a way to have (some of) your users have some level of trust. Or don't execute anyone's uploads. If you allow people to upload code, make them say it's code (via extension *and* by putting it in an executable area). It is not difficult to predict whether a file will be processed by PHP before worrying about what PHP would do with it. If people really worried as much as they claim to about execution of any old document, robots, htaccess, ds_stores -- and php.inis, for that matter -- would be considered highly dangerous. -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
