Bug #52144 [Fbk->Opn]: Error: Base lambda function for closure not found
Edit report at http://bugs.php.net/bug.php?id=52144&edit=1
ID: 52144
User updated by: taco at procurios dot nl
Reported by: taco at procurios dot nl
Summary: Error: Base lambda function for closure not found
-Status: Feedback
+Status: Open
Type: Bug
Package: *Programming Data Structures
Operating System: linux
PHP Version: 5.3.2
New Comment:
The code in which the problem occurred looks like:
function (&$v)
{
if (!empty($v)) {
$v /= 13.66;
}
return true;
},
// ...some other lambda functions
);
// ...code that uses the array with lambda functions
?>
The error occurs at the definition of the first lambda function in the
array. The problem is that the error isn't reproducable (at least not
when I want it to be). That's why I'd like to know what the typical
situation is in which this error could occur.
Previous Comments:
[2010-06-22 15:09:52] johan...@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
Please also ensure that you're having no Zend extension or opcode cache
or similar loaded.
----
[2010-06-22 13:30:52] taco at procurios dot nl
Description:
I've rewritten some create_function() calls to lambda functions. After
updating our servers with the new code the following error started to
occur on one of the servers:
"Base lambda function for closure not found"
We immediately replaced the new code with the old and tried to figure
out what went wrong. Since we couldn't find the bug and on development
machines nothing went wrong, we gave the new code another try:
everything worked like expected, without errors.
I'd really like to know what could have triggered this error, especially
because we didn't change the code that triggered it.
--
Edit this bug report at http://bugs.php.net/bug.php?id=52144&edit=1
[PHP-BUG] Bug #52144 [NEW]: Error: Base lambda function for closure not found
From: Operating system: linux PHP version: 5.3.2 Package: *Programming Data Structures Bug Type: Bug Bug description:Error: Base lambda function for closure not found Description: I've rewritten some create_function() calls to lambda functions. After updating our servers with the new code the following error started to occur on one of the servers: "Base lambda function for closure not found" We immediately replaced the new code with the old and tried to figure out what went wrong. Since we couldn't find the bug and on development machines nothing went wrong, we gave the new code another try: everything worked like expected, without errors. I'd really like to know what could have triggered this error, especially because we didn't change the code that triggered it. -- Edit bug report at http://bugs.php.net/bug.php?id=52144&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52144&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52144&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52144&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52144&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52144&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52144&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52144&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52144&r=needscript Try newer version: http://bugs.php.net/fix.php?id=52144&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52144&r=support Expected behavior: http://bugs.php.net/fix.php?id=52144&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52144&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52144&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52144&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52144&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52144&r=dst IIS Stability: http://bugs.php.net/fix.php?id=52144&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52144&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52144&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52144&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52144&r=mysqlcfg
#47838 [NEW]: For some strict notices __autoload isn't used in the error handler
From: taco at procurios dot nl
Operating system: Ubuntu
PHP version: 5.2.9
PHP Bug Type: Unknown/Other Function
Bug description: For some strict notices __autoload isn't used in the error
handler
Description:
We dynamicly load a logging class in our error handler function using
autoload. For some STRICT notices (Declaration of Baz::bar() should be
compatible with that of Foo::bar()) the __autoload() function isn't called
to load that logging class.
If you replace the line "require('php_bug1_2.php');" with "mktime();",
which also casts an E_STRICT notice, you'll see the expected result instead
of the missing Qux class error.
Reproduce code:
---
http://thh.takkie.nl/php_bug1.php
Expected result:
My Error: Declaration of Baz::bar() should be compatible with that of
Foo::bar()
Stuff is done
Actual result:
--
My Error: Declaration of Baz::bar() should be compatible with that of
Foo::bar()
Fatal error: Class 'Qux' not found in
/data/www/thh.takkie.nl/public_html/php_bug1_2.php on line 15
--
Edit bug report at http://bugs.php.net/?id=47838&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47838&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47838&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47838&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47838&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=47838&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47838&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=47838&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=47838&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=47838&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=47838&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=47838&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=47838&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=47838&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47838&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47838&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47838&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=47838&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=47838&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=47838&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=47838&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=47838&r=mysqlcfg
#46556 [Com]: There is no good method to escape a string for use in a (mySQL) LIKE clause
ID: 46556 Comment by: taco at procurios dot nl Reported By: taco at procurios dot nl Status: Open Bug Type: PDO related Operating System: linux PHP Version: 5.2.6 Assigned To: johannes New Comment: There is no need for such a method in mysqli because mysqli_real_escape_string() does not add quotes to the resulting string. Using mysqli you would be able to do this: $q = "SELECT...WHERE `foo` LIKE '%" . addcslashes($MySQLi->real_escape_string($evilVar), '%_') . "%'"; In PDO this is impossible because of the added quotes. Previous Comments: [2008-11-13 15:30:49] [EMAIL PROTECTED] Maybe something for PDOv2 or mysqli? -------- [2008-11-12 15:56:53] taco at procurios dot nl Description: There is no good method to escape a string for use in a (mySQL) LIKE clause. In a query like "SELECT `foo` FROM `bar` WHERE `baz` LIKE '%" . $qux . "%'" the value of $qux should be escaped for both the query itself (like PDO::quote() does) as the LIKE clause (i.e. escaping % and _ characters. Using PDO the only way to escape a variable is using either PDOStatement::bindParam() or PDO::quote(). The first is not suitable for two reasons: 1. Not every query is a prepared statement 2. There is no way to escape % and _ (escaping them first will result in the \ being escaped: \% becomes \\%) The latter is not suitable because it will add quotes to the string, so you'll have to get rid of the quotes, escape % and _ and add the result to the query. -- Edit this bug report at http://bugs.php.net/?id=46556&edit=1
#46556 [NEW]: There is no good method to escape a string for use in a (mySQL) LIKE clause
From: taco at procurios dot nl Operating system: linux PHP version: 5.2.6 PHP Bug Type: PDO related Bug description: There is no good method to escape a string for use in a (mySQL) LIKE clause Description: There is no good method to escape a string for use in a (mySQL) LIKE clause. In a query like "SELECT `foo` FROM `bar` WHERE `baz` LIKE '%" . $qux . "%'" the value of $qux should be escaped for both the query itself (like PDO::quote() does) as the LIKE clause (i.e. escaping % and _ characters. Using PDO the only way to escape a variable is using either PDOStatement::bindParam() or PDO::quote(). The first is not suitable for two reasons: 1. Not every query is a prepared statement 2. There is no way to escape % and _ (escaping them first will result in the \ being escaped: \% becomes \\%) The latter is not suitable because it will add quotes to the string, so you'll have to get rid of the quotes, escape % and _ and add the result to the query. -- Edit bug report at http://bugs.php.net/?id=46556&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=46556&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=46556&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=46556&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=46556&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=46556&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=46556&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=46556&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=46556&r=needscript Try newer version: http://bugs.php.net/fix.php?id=46556&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=46556&r=support Expected behavior: http://bugs.php.net/fix.php?id=46556&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=46556&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=46556&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=46556&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46556&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=46556&r=dst IIS Stability: http://bugs.php.net/fix.php?id=46556&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=46556&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=46556&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=46556&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=46556&r=mysqlcfg
#46533 [NEW]: PDOStatement::getColumnMeta lacks some information regarding aliases
From: taco at procurios dot nl
Operating system: Linux
PHP version: 5.2.6
PHP Bug Type: PDO related
Bug description: PDOStatement::getColumnMeta lacks some information regarding
aliases
Description:
When using aliases for tables and/or columns in a MySQL query. The method
PDOStatement::getColumnMeta() will not tell you anything about the original
table / column name. In the MySQLi extension the information about the
original table / column name was represented as 'orgtable' and 'orgname'
this would be a very nice addition to the PDO extension.
Reproduce code:
---
SQL:
CREATE TABLE `foobar` (
`bar` varchar(255) default NULL
) ENGINE=MEMORY;
PHP:
print_r(
$PDO->query("SELECT foo.bar as baz FROM foobar foo")
->getColumnMeta(0)
);
Expected result:
Array
(
[native_type] => VAR_STRING
[flags] => Array
(
)
[table] => foo
[orgtable] => foobar
[name] => baz
[orgname] => bar
[len] => 255
[precision] => 0
[pdo_type] => 2
)
Actual result:
--
Array
(
[native_type] => VAR_STRING
[flags] => Array
(
)
[table] => foo
[name] => baz
[len] => 255
[precision] => 0
[pdo_type] => 2
)
--
Edit bug report at http://bugs.php.net/?id=46533&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=46533&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=46533&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=46533&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=46533&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=46533&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=46533&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=46533&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=46533&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=46533&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=46533&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=46533&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=46533&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=46533&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=46533&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46533&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=46533&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=46533&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=46533&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=46533&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=46533&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=46533&r=mysqlcfg
#45299 [Fbk->Opn]: serialize / unserialize $GLOBALS breaks global objects
ID: 45299
User updated by: taco at procurios dot nl
Reported By: taco at procurios dot nl
-Status: Feedback
+Status: Open
Bug Type: Class/Object related
Operating System: linux
PHP Version: 5.2.6
New Comment:
I don't ;)
I encountered this 'bug' while using PHPUnit, see:
http://www.phpunit.de/browser/phpunit/trunk/PHPUnit/Framework/TestCase.php#L370
Previous Comments:
[2008-07-03 11:53:02] [EMAIL PROTECTED]
Please tell us WHY do you want to serialize special super global arrays
like $GLOBALS in the first place?! That's propably the dummiest idea
ever..
[2008-06-18 12:03:24] taco at procurios dot nl
Description:
When serializing and later on deserializing the $GLOBALS array, global
objects aren't recreated.
Reproduce code:
---
class Foo
{
public $foo;
public function __construct($foo)
{
$this->foo = $foo;
}
}
$Foo = new Foo(34);
var_dump($GLOBALS['Foo']);
$s = serialize($GLOBALS);
$GLOBALS = unserialize($s);
var_dump($GLOBALS['Foo']);
Expected result:
object(Foo)#1 (1) {
["foo"]=>
int(34)
}
object(Foo)#1 (1) {
["foo"]=>
int(34)
}
Actual result:
--
object(Foo)#1 (1) {
["foo"]=>
int(34)
}
int(1)
--
Edit this bug report at http://bugs.php.net/?id=45299&edit=1
#45299 [NEW]: serialize / unserialize $GLOBALS breaks global objects
From: taco at procurios dot nl
Operating system: linux
PHP version: 5.2.6
PHP Bug Type: Class/Object related
Bug description: serialize / unserialize $GLOBALS breaks global objects
Description:
When serializing and later on deserializing the $GLOBALS array, global
objects aren't recreated.
Reproduce code:
---
class Foo
{
public $foo;
public function __construct($foo)
{
$this->foo = $foo;
}
}
$Foo = new Foo(34);
var_dump($GLOBALS['Foo']);
$s = serialize($GLOBALS);
$GLOBALS = unserialize($s);
var_dump($GLOBALS['Foo']);
Expected result:
object(Foo)#1 (1) {
["foo"]=>
int(34)
}
object(Foo)#1 (1) {
["foo"]=>
int(34)
}
Actual result:
--
object(Foo)#1 (1) {
["foo"]=>
int(34)
}
int(1)
--
Edit bug report at http://bugs.php.net/?id=45299&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=45299&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=45299&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=45299&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=45299&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=45299&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=45299&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=45299&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=45299&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=45299&r=support
Expected behavior:http://bugs.php.net/fix.php?id=45299&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=45299&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=45299&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=45299&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45299&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=45299&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=45299&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=45299&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=45299&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=45299&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=45299&r=mysqlcfg
#40802 [Bgs]: number_format does not fill rounded number with zeros
ID: 40802 User updated by: taco at procurios dot nl Reported By: taco at procurios dot nl Status: Bogus Bug Type: *Math Functions Operating System: Linux 2.6.17-11-386 PHP Version: 5.2.1 New Comment: Nevermind. Forgot to look at the manual, the number argument should be a float... Previous Comments: [2007-03-14 10:32:09] taco at procurios dot nl I agree that this is normal behaviour for floats, but the same bug appears when you would pass a string. Does number_format cast strings to floats internally? [2007-03-14 10:09:47] [EMAIL PROTECTED] Floating point values have a limited precision. Hence a value might not have the same string representation after any processing. That also includes writing a floating point value in your script and directly printing it without any mathematical operations. If you would like to know more about "floats" and what IEEE 754 is read this: http://docs.sun.com/source/806-3568/ncg_goldberg.html Thank you for your interest in PHP. [2007-03-14 10:07:19] taco at procurios dot nl Description: Since there is no way to tell number_format to use a specified decimal separator and thousands separator without rounding the number I wanted to set the amount of decimals bigger than the given amount of decimals to strip the trailing zeros afterwards. However, the string number_format returned did not only add zeros to the given number: $ php -v PHP 5.2.1-0.dotdeb.1 with Suhosin-Patch 0.9.6.2 (cli) (built: Feb 9 2007 04:46:32) Copyright (c) 1997-2007 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies $ php -r "echo number_format(2.33, 60, ',', '.');" 2,3301014370809571119025349617004394531250 Reproduce code: --- echo number_format(2.33, 60, ',', '.'); Expected result: 2,3300 Actual result: -- 2,3301014370809571119025349617004394531250 -- Edit this bug report at http://bugs.php.net/?id=40802&edit=1
#40802 [Bgs]: number_format does not fill rounded number with zeros
ID: 40802 User updated by: taco at procurios dot nl Reported By: taco at procurios dot nl Status: Bogus Bug Type: *Math Functions Operating System: Linux 2.6.17-11-386 PHP Version: 5.2.1 New Comment: I agree that this is normal behaviour for floats, but the same bug appears when you would pass a string. Does number_format cast strings to floats internally? Previous Comments: [2007-03-14 10:09:47] [EMAIL PROTECTED] Floating point values have a limited precision. Hence a value might not have the same string representation after any processing. That also includes writing a floating point value in your script and directly printing it without any mathematical operations. If you would like to know more about "floats" and what IEEE 754 is read this: http://docs.sun.com/source/806-3568/ncg_goldberg.html Thank you for your interest in PHP. [2007-03-14 10:07:19] taco at procurios dot nl Description: Since there is no way to tell number_format to use a specified decimal separator and thousands separator without rounding the number I wanted to set the amount of decimals bigger than the given amount of decimals to strip the trailing zeros afterwards. However, the string number_format returned did not only add zeros to the given number: $ php -v PHP 5.2.1-0.dotdeb.1 with Suhosin-Patch 0.9.6.2 (cli) (built: Feb 9 2007 04:46:32) Copyright (c) 1997-2007 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies $ php -r "echo number_format(2.33, 60, ',', '.');" 2,3301014370809571119025349617004394531250 Reproduce code: --- echo number_format(2.33, 60, ',', '.'); Expected result: 2,3300 Actual result: -- 2,3301014370809571119025349617004394531250 -- Edit this bug report at http://bugs.php.net/?id=40802&edit=1
#40802 [NEW]: number_format does not fill rounded number with zeros
From: taco at procurios dot nl Operating system: Linux 2.6.17-11-386 PHP version: 5.2.1 PHP Bug Type: *Math Functions Bug description: number_format does not fill rounded number with zeros Description: Since there is no way to tell number_format to use a specified decimal separator and thousands separator without rounding the number I wanted to set the amount of decimals bigger than the given amount of decimals to strip the trailing zeros afterwards. However, the string number_format returned did not only add zeros to the given number: $ php -v PHP 5.2.1-0.dotdeb.1 with Suhosin-Patch 0.9.6.2 (cli) (built: Feb 9 2007 04:46:32) Copyright (c) 1997-2007 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies $ php -r "echo number_format(2.33, 60, ',', '.');" 2,3301014370809571119025349617004394531250 Reproduce code: --- echo number_format(2.33, 60, ',', '.'); Expected result: 2,3300 Actual result: -- 2,3301014370809571119025349617004394531250 -- Edit bug report at http://bugs.php.net/?id=40802&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=40802&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=40802&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=40802&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=40802&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=40802&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=40802&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=40802&r=needscript Try newer version:http://bugs.php.net/fix.php?id=40802&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=40802&r=support Expected behavior:http://bugs.php.net/fix.php?id=40802&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=40802&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=40802&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=40802&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40802&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=40802&r=dst IIS Stability:http://bugs.php.net/fix.php?id=40802&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=40802&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=40802&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=40802&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=40802&r=mysqlcfg
#38579 [Com]: require_once() distinguishes backslashes from forward slashes
ID: 38579
Comment by: taco at procurios dot nl
Reported By: frank at procurios dot nl
Status: Open
Bug Type: Scripting Engine problem
Operating System: Windows
PHP Version: 5.1.5
New Comment:
I'm experiencing this bug too. Besides the slashes also differences in
drive letter case seem to interfere with the require_once cache:
requiring the path C:/path/file.php in the __autoload function will not
prevent the file c:/path/file.php from being required a second time
using require_once.
Previous Comments:
[2006-08-24 10:30:50] frank at procurios dot nl
For sake of clarity, a minor typo needs to be corrected:
// Some function that doesn't resolves paths
Should be
// Some function that doesn't do anything but resolve paths
[2006-08-24 10:27:32] frank at procurios dot nl
Description:
When including a file, require_once() will make a destinction between
path/file strings containing forward slashes and backslashes.
Reproduce code:
---
(example)
function __autoload($className){
$basePath = 'C:/htdocs';
$classPath= $basePath . '/classes';
require_once($classPath . "/$className.class.php");
}
// Some function that doesn't resolves paths
function getPath($file){
$path = realpath('./$file');
return $path;
}
// Autoload
$A = new Foo;
// Explicit require of class
require_once(getPath(Foo.class.php));
$B = new Foo;
Expected result:
One would expect the require_once to notice that Foo has already been
loaded and not include the file a second time.
Actual result:
--
Fatal error: Cannot redeclare class foo in
c:\htdocs\classes\Foo.class.php on line n
(or something like that)
Whatever the actual result, the file is loaded twice, as the slashes
produced by realpath are distinguished from the slashes used in the
defined __autoload() function.
--
Edit this bug report at http://bugs.php.net/?id=38579&edit=1
