#48693 [NEW]: Double declaration of __lambda_func when lambda wrongly formatted
From: peter at lvp-media dot com
Operating system: n/a
PHP version: 5.3CVS-2009-06-25 (snap)
PHP Bug Type: Scripting Engine problem
Bug description: Double declaration of __lambda_func when lambda wrongly
formatted
Description:
When creating a new lambda function using create_function, any code behind
an extra right curly brace (which closes the function) gets executed. This
is known and expected behaviour of eval, so no problem so far. However,
when the function itself does not contain parsing errors, while the code
after it does, the function gets created (and becomes available) while
zend_eval_stringl() returns false. Therefore the function's name,
defaulting to LAMBDA_TEMP_FUNCNAME, will not be changed and any future
calls to create_functions will fail using a fatal error ("Cannot redeclare
__lambda_func()"). Reproduce code is included.
The echo should output "1", however, the fatal error gets thrown instead.
While this absolutely isn't a problem that (should) occur very often,
fixing it seemed fairly easy so I created two patches.
The first patch checks whether any function named LAMBDA_TEMP_FUNCNAME
exists if zend_eval_stringl() fails, and if it does, renames it to
lambda_%d as would be done if the eval succeeded. After all, the function
itself was fine, so the function name can be returned as well.
zend_eval_stringl() outputs the parse error automatically so the
script-owner gets informed of the problem as well. The second patch is
easier, it simply removes any function called LAMBDA_TEMP_FUNCNAME if it
exists.
PATCH 1:
--- zend_builtin_functions.c2009-06-25 15:23:45.0 +0200
+++ zend_builtin_functions_new.c2009-06-25 15:40:34.0
+0200
@@ -1737,8 +1737,8 @@ ZEND_FUNCTION(create_function)
efree(eval_name);
- if (retval==SUCCESS) {
+ if (retval==SUCCESS || zend_hash_find(EG(function_table),
LAMBDA_TEMP_FUNCNAME, sizeof(LAMBDA_TEMP_FUNCNAME), (void **)
&func)!=FAILURE) {
zend_function new_function, *func;
- if (zend_hash_find(EG(function_table),
LAMBDA_TEMP_FUNCNAME, sizeof(LAMBDA_TEMP_FUNCNAME), (void **)
&func)==FAILURE) {
+ if (retval==SUCCESS && zend_hash_find(EG(function_table),
LAMBDA_TEMP_FUNCNAME, sizeof(LAMBDA_TEMP_FUNCNAME), (void **)
&func)==FAILURE) {
zend_error(E_ERROR, "Unexpected inconsistency in
create_function()");
RETURN_FALSE;
PATCH 2:
--- zend_builtin_functions.c2009-06-25 15:23:45.0
+0200
+++ zend_builtin_functions_new.c2009-06-25 15:23:45.0
+0200
@@ -1756,4 +1756,7 @@ ZEND_FUNCTION(create_function)
RETURN_STRINGL(function_name, function_name_length, 0);
} else {
+if (zend_hash_find(EG(function_table),
LAMBDA_TEMP_FUNCNAME, sizeof(LAMBDA_TEMP_FUNCNAME), (void **)
&func)!=FAILURE) {
+ zend_hash_del(EG(function_table),
LAMBDA_TEMP_FUNCNAME, sizeof(LAMBDA_TEMP_FUNCNAME));
+ }
RETURN_FALSE;
}
Reproduce code:
---
Expected result:
1
Actual result:
--
Fatal error: Cannot redeclare __lambda_func() (previously declared in
/home/peter/test.php(2) : runtime-created function:
--
Edit bug report at http://bugs.php.net/?id=48693&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48693&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48693&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48693&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48693&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=48693&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48693&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=48693&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=48693&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=48693&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=48693&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=48693&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=48693&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=48693&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48693&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48693&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48693&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=48693&r=isapi
Insta
#48693 [Com]: Double declaration of __lambda_func when lambda wrongly formatted
ID: 48693
Comment by: peter at lvp-media dot com
Reported By: peter at lvp-media dot com
Status: Open
Bug Type: Scripting Engine problem
Operating System: n/a
PHP Version: 5.3CVS-2009-06-25 (snap)
New Comment:
The reproduce code got cut off, the else{} should be in the comment
right behind the $borked-assignment.
Previous Comments:
[2009-06-25 13:46:51] peter at lvp-media dot com
Description:
When creating a new lambda function using create_function, any code
behind an extra right curly brace (which closes the function) gets
executed. This is known and expected behaviour of eval, so no problem so
far. However, when the function itself does not contain parsing errors,
while the code after it does, the function gets created (and becomes
available) while zend_eval_stringl() returns false. Therefore the
function's name, defaulting to LAMBDA_TEMP_FUNCNAME, will not be changed
and any future calls to create_functions will fail using a fatal error
("Cannot redeclare __lambda_func()"). Reproduce code is included.
The echo should output "1", however, the fatal error gets thrown
instead. While this absolutely isn't a problem that (should) occur very
often, fixing it seemed fairly easy so I created two patches.
The first patch checks whether any function named LAMBDA_TEMP_FUNCNAME
exists if zend_eval_stringl() fails, and if it does, renames it to
lambda_%d as would be done if the eval succeeded. After all, the
function itself was fine, so the function name can be returned as well.
zend_eval_stringl() outputs the parse error automatically so the
script-owner gets informed of the problem as well. The second patch is
easier, it simply removes any function called LAMBDA_TEMP_FUNCNAME if it
exists.
PATCH 1:
--- zend_builtin_functions.c2009-06-25 15:23:45.0 +0200
+++ zend_builtin_functions_new.c2009-06-25 15:40:34.0
+0200
@@ -1737,8 +1737,8 @@ ZEND_FUNCTION(create_function)
efree(eval_name);
- if (retval==SUCCESS) {
+ if (retval==SUCCESS || zend_hash_find(EG(function_table),
LAMBDA_TEMP_FUNCNAME, sizeof(LAMBDA_TEMP_FUNCNAME), (void **)
&func)!=FAILURE) {
zend_function new_function, *func;
- if (zend_hash_find(EG(function_table),
LAMBDA_TEMP_FUNCNAME, sizeof(LAMBDA_TEMP_FUNCNAME), (void **)
&func)==FAILURE) {
+ if (retval==SUCCESS &&
zend_hash_find(EG(function_table), LAMBDA_TEMP_FUNCNAME,
sizeof(LAMBDA_TEMP_FUNCNAME), (void **) &func)==FAILURE) {
zend_error(E_ERROR, "Unexpected inconsistency
in create_function()");
RETURN_FALSE;
PATCH 2:
--- zend_builtin_functions.c2009-06-25 15:23:45.0
+0200
+++ zend_builtin_functions_new.c2009-06-25 15:23:45.0
+0200
@@ -1756,4 +1756,7 @@ ZEND_FUNCTION(create_function)
RETURN_STRINGL(function_name, function_name_length,
0);
} else {
+if (zend_hash_find(EG(function_table),
LAMBDA_TEMP_FUNCNAME, sizeof(LAMBDA_TEMP_FUNCNAME), (void **)
&func)!=FAILURE) {
+ zend_hash_del(EG(function_table),
LAMBDA_TEMP_FUNCNAME, sizeof(LAMBDA_TEMP_FUNCNAME));
+ }
RETURN_FALSE;
}
Reproduce code:
---
Expected result:
1
Actual result:
--
Fatal error: Cannot redeclare __lambda_func() (previously declared in
/home/peter/test.php(2) : runtime-created function:
--
Edit this bug report at http://bugs.php.net/?id=48693&edit=1
#40579 [Com]: $_SERVER['SERVER_PORT'] is invalid during apache redirect
ID: 40579
Comment by: peter at lvp-media dot com
Reported By: ruslan dot kyrychuk at gmail dot com
Status: No Feedback
Bug Type: *Web Server problem
Operating System: Windows 2003
PHP Version: 5.2.1
New Comment:
This isn't a PHP-specific bug, it seems to be a problem within
mod_rewrite or Apache itself. I ran into this problem as well, but was
able to reproduce it with Perl and C scripts. For completeness, I'm
running PHP 5.3-dev on Linux with Apache 2.2.
Previous Comments:
[2009-01-26 15:06:38] tim at timloram dot me dot uk
I am experiencing this issue with exact same symptoms. Having used
mod_rewrite to redirect incoming requests to central gateway script,
$_SERVER['SERVER_PORT'] is always reading '80' even if my inital URL was
http://abc.com:86
Any ideas?
[2007-03-31 01:00:00] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[2007-03-23 11:10:51] tony2...@php.net
Works just fine here.
["SERVER_PORT"]=> string(4) "8887"
["SCRIPT_NAME"]=> string(11) "/index.html"
[2007-03-23 10:58:01] ruslan dot kyrychuk at gmail dot com
Reproduce code:
---
1. Configure Apache to use port 8080
2. Create .htaccess file:
Options +FollowSymLinks -Indexes
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} (.+)\.html
RewriteRule ^(.+)$ test.php [QSA,L]
3. Create test.php file
Run http://localhost:8080/test.html
Output: 80
Run http://localhost:8080/test.php
Output: 8080
[2007-03-01 01:00:01] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/40579
--
Edit this bug report at http://bugs.php.net/?id=40579&edit=1
#47752 [Com]: FILTER_VALIDATE_INT doesn't allow "+0" and "-0"
ID: 47752
Comment by: peter at lvp-media dot com
Reported By: for-bugs at hnw dot jp
Status: Feedback
Bug Type: Filter related
Operating System: *
PHP Version: 5.2.9
Assigned To: pajoye
New Comment:
Hereby a simple bug47752.phpt file. Tested it on a patched- an an
unpatched installation, results as expected. Strictly speaking +0 and -0
are valid integers, even though neither of them is positive or
negative.
Peter Beverloo
--TEST--
Bug #47752 (FILTER_VALIDATE_INT doesn't allow "+0" and "-0")
--FILE--
--EXPECT--
int(0)
int(0)
int(0)
bool(false)
Previous Comments:
[2009-03-24 12:44:19] paj...@php.net
As far as I remember it is on purpose. 0 cannot be negative or
positive.
But if we agree on allowing them again, no problem here.
Can you please provide tests as well (phpt)?
[2009-03-24 11:50:38] php at lvp-media dot com
False, this only allows +0 and -0 by checking the lenght of the string,
it verifies that the null is the only character in it.
[2009-03-24 11:49:06] der...@php.net
Right, so this patch is not correct as it would allow octal numbers.
[2009-03-24 11:46:57] php at lvp-media dot com
Probably the easiest fix for this would be to change line 88 of
logical_filters.c to allow the character "0" as well, seeing values like
-0012 and 0012 get returned as false now as well. Con of this is quite
obvious as well however, as numbers prefixed by 0 often get interpreted
as octal numbers.
A better fix would be to add a check for it;
--- logical_filters.bak 2009-03-24 12:43:23.0 +0100
+++ logical_filters.c2009-03-24 12:45:09.0 +0100
@@ -84,6 +84,12 @@
break;
}
+ /* allow +0 and -0 */
+ if ((str + 1) == end && *str == '0') {
+ *ret = 0;
+ return 1;
+ }
+
/* must start with 1..9*/
if (str < end && *str >= '1' && *str <= '9') {
ctx_value = ((*(str++)) - '0');
[2009-03-23 05:40:58] for-bugs at hnw dot jp
Description:
FILTER_VALIDATE_INT doesn't allow "+0" and "-0",
while "0", "+1", and "-1" is valid.
Reproduce code:
---
http://bugs.php.net/?id=47752&edit=1
