#35738 [Opn->Bgs]: how to declare a non static method
ID: 35738 Updated by: [EMAIL PROTECTED] Reported By: sqchen at citiz dot net -Status: Open +Status: Bogus Bug Type: Class/Object related Operating System: redhat 7.3 PHP Version: 5.1.1 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. . Previous Comments: [2005-12-20 05:24:43] sqchen at citiz dot net Description: as php manual says: http://www.php.net/manual/en/language.oop5.static.php if a method is declared as just public, it will be no static method, right? it not, how to declared a no static method Reproduce code: --- Expected result: warning: [static_foo] Actual result: -- [foo] [static_foo] -- Edit this bug report at http://bugs.php.net/?id=35738&edit=1
#35738 [NEW]: how to declare a non static method
From: sqchen at citiz dot net Operating system: redhat 7.3 PHP version: 5.1.1 PHP Bug Type: Class/Object related Bug description: how to declare a non static method Description: as php manual says: http://www.php.net/manual/en/language.oop5.static.php if a method is declared as just public, it will be no static method, right? it not, how to declared a no static method Reproduce code: --- Expected result: warning: [static_foo] Actual result: -- [foo] [static_foo] -- Edit bug report at http://bugs.php.net/?id=35738&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=35738&r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=35738&r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=35738&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=35738&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=35738&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=35738&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=35738&r=needscript Try newer version:http://bugs.php.net/fix.php?id=35738&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=35738&r=support Expected behavior:http://bugs.php.net/fix.php?id=35738&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=35738&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=35738&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=35738&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=35738&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=35738&r=dst IIS Stability:http://bugs.php.net/fix.php?id=35738&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=35738&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=35738&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=35738&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=35738&r=mysqlcfg
#35737 [NEW]: undefined symbol: sqlite3SelectDelete
From: jphml at videotron dot ca Operating system: Linux PHP version: 5.1.1 PHP Bug Type: Apache2 related Bug description: undefined symbol: sqlite3SelectDelete Description: When tring to use Apache 2.0.55 with PHP 5.1.1 module (libphp5.so) you get the following error on Apache startup Syntax error on line 232 of /opt/fruity/conf/httpd.conf: Cannot load /opt/fruity/modules/libphp5.so into server: /opt/fruity/modules/libphp5.so: undefined symbol: sqlite3SelectDelete Your are then unable to start apache. Here is my configure line for Apache: ./configure --prefix=/opt/fruity --enable-so Here is my configure line for PHP 5.1.1: ./configure --prefix=/opt/fruity --with-apxs2=/opt/fruity/bin/apxs --with-mysql Here is my line about PHP in httpd.conf LoadModule php5_modulemodules/libphp5.so I tried the following: - Apache 1.3.34 with PHP 5.1.1: same error - Compile PHP 5.1.1 with --without-sqlite: Same error - Compile PHP without --with-mysql: Same error The following configuration works: Apache 2.0.55 and PHP 5.0.5 with the configure lines above. (In Apache 1.x use --enable-module=so instead of --enable-so). Note that both software were always compiled with --prefix=/opt/fruity, I didn't tried without. Expected result: You expect that Apache will start without errors Actual result: -- When you start apache you get: [EMAIL PROTECTED] bin]# ./apachectl start Syntax error on line 232 of /opt/fruity/conf/httpd.conf: Cannot load /opt/fruity/modules/libphp5.so into server: /opt/fruity/modules/libphp5.so: undefined symbol: sqlite3SelectDelete and Apache doesn't start -- Edit bug report at http://bugs.php.net/?id=35737&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=35737&r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=35737&r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=35737&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=35737&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=35737&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=35737&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=35737&r=needscript Try newer version:http://bugs.php.net/fix.php?id=35737&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=35737&r=support Expected behavior:http://bugs.php.net/fix.php?id=35737&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=35737&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=35737&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=35737&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=35737&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=35737&r=dst IIS Stability:http://bugs.php.net/fix.php?id=35737&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=35737&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=35737&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=35737&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=35737&r=mysqlcfg
#35730 [Opn->Fbk]: mssql didn't use the right character encoding in freetds.conf
ID: 35730 Updated by: [EMAIL PROTECTED] Reported By: liang at saga-city dot com -Status: Open +Status: Feedback Bug Type: MSSQL related Operating System: FreeBSD PHP Version: 5.1.1 Assigned To: fmk New Comment: Please try to upgrade to the latest CVS version of FreeTDS. As I mentioned before all the encoding stuff is handled by FreeTDS. There is no encoding handling in the code for the PHP extension and the code differences between version 4, 5.0, 5.1 and 6.0 of PHP are only related to internal PHP stuff and has nothing to do with how the library is used. Previous Comments: [2005-12-20 01:37:48] liang at saga-city dot com We have some production machines with PHP5.0.3/FreeBSD5.4/FreeTDS0.62.4 installed, All works great. Now we are setting a clean and new FreeBSD 6.0 system box with only freetds-0.63 mysql5.0-client and apache22 installed. It's obvious testing PHP4/PHP5 installation link to the same freetds library. [2005-12-19 18:12:27] [EMAIL PROTECTED] Are you absolutely sure you're linking PHP with the same freetds library as you did with PHP 4? [2005-12-19 05:48:08] liang at saga-city dot com we have been testing the mssql extension both in PHP4 and PHP5.1.1, " with the same freetds.conf " tds version = 8.0 client charset = BIG-5 In php4, it works fine, but not in php5.1.1 ( our old system uses php5.0.3 also work fine in the "same" freetds.conf ) [2005-12-19 03:27:06] [EMAIL PROTECTED] All encoding is handled by freetds in both PHP4 and PHP5. Execpt for internal PHP stuff the mssql extension is the same for PHP4 and PHP5. You need to change the encoding in freetds.conf. [2005-12-19 02:29:00] liang at saga-city dot com Description: php5 mssql didn't use character encoding specify in freetds.conf ( alwasy use ISO-8559-1 , seen in freetds.log ) switch to php4 , everythings works fine -- Edit this bug report at http://bugs.php.net/?id=35730&edit=1
#35730 [Fbk->Opn]: mssql didn't use the right character encoding in freetds.conf
ID: 35730 User updated by: liang at saga-city dot com Reported By: liang at saga-city dot com -Status: Feedback +Status: Open Bug Type: MSSQL related Operating System: FreeBSD PHP Version: 5.1.1 Assigned To: fmk New Comment: We have some production machines with PHP5.0.3/FreeBSD5.4/FreeTDS0.62.4 installed, All works great. Now we are setting a clean and new FreeBSD 6.0 system box with only freetds-0.63 mysql5.0-client and apache22 installed. It's obvious testing PHP4/PHP5 installation link to the same freetds library. Previous Comments: [2005-12-19 18:12:27] [EMAIL PROTECTED] Are you absolutely sure you're linking PHP with the same freetds library as you did with PHP 4? [2005-12-19 05:48:08] liang at saga-city dot com we have been testing the mssql extension both in PHP4 and PHP5.1.1, " with the same freetds.conf " tds version = 8.0 client charset = BIG-5 In php4, it works fine, but not in php5.1.1 ( our old system uses php5.0.3 also work fine in the "same" freetds.conf ) [2005-12-19 03:27:06] [EMAIL PROTECTED] All encoding is handled by freetds in both PHP4 and PHP5. Execpt for internal PHP stuff the mssql extension is the same for PHP4 and PHP5. You need to change the encoding in freetds.conf. [2005-12-19 02:29:00] liang at saga-city dot com Description: php5 mssql didn't use character encoding specify in freetds.conf ( alwasy use ISO-8559-1 , seen in freetds.log ) switch to php4 , everythings works fine -- Edit this bug report at http://bugs.php.net/?id=35730&edit=1
#33115 [Fbk->Csd]: Windows Install Silent Option breaks OS environment path variable
ID: 33115 User updated by: john dot jantjes at gmail dot com Reported By: john dot jantjes at gmail dot com -Status: Feedback +Status: Closed Bug Type: IIS related Operating System: Windows XP PHP Version: 5.0.4, 4.3.11 Assigned To: phildriscoll New Comment: No, 5.1 has resolved this issue. This ticket can be closed. Previous Comments: [2005-12-19 09:08:22] [EMAIL PROTECTED] Does this happen with the latest release? (5.1.1) [2005-11-07 00:03:50] [EMAIL PROTECTED] Phil, have you checked this report yet..? [2005-05-24 04:20:36] john dot jantjes at gmail dot com If the installer is used normally, not silent, the issue does not appear. [2005-05-24 04:16:42] john dot jantjes at gmail dot com Description: I have been using the windows installer, with the "/s" option for a silent install, and have found that it breaks the OS environment variable. For example Instread of path being path=c:\windows;c:\windows\system32; . It becomes path=%SystemRoot%;%SystemRoot%\system32;.. It set the path variable to reference another variable, which just does not seem to work. Only the windows and windows system entries in path are effected. -- Edit this bug report at http://bugs.php.net/?id=33115&edit=1
#35736 [Opn->Bgs]: PHP loads only PART of a page
ID: 35736 Updated by: [EMAIL PROTECTED] Reported By: webmaster at mentalworkshop dot com -Status: Open +Status: Bogus Bug Type: *Web Server problem Operating System: Win XP without SP1 or 2 PHP Version: 4.4.1 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. Previous Comments: [2005-12-20 00:49:06] webmaster at mentalworkshop dot com Description: I'm using Xoops. In the administration control panel, the pages in there are only partly displayed when loaded. The buttons and positioning are misplaced and messed up. When I click refresh, it gets messed up more. But it is just luck. After 4-6 refreshes, I usually get the entire page to load. Then I can continue what I'm doing. But this really bugs me because I have to sit there and click refresh all the time... By the way, it's not the xoops problem. PHP will do this to me when a BIG php file is loaded. I think it's a configuration of php.ini. Maybe there is a "time out?" or something because my server is not strong enough..? I have a P3 900 Mhz. 512 RAM. No SP1. No SP2. Apache/MYSQL configured correctly. Thank you -- Edit this bug report at http://bugs.php.net/?id=35736&edit=1
#35736 [NEW]: PHP loads only PART of a page
From: webmaster at mentalworkshop dot com Operating system: Win XP without SP1 or 2 PHP version: 4.4.1 PHP Bug Type: *Web Server problem Bug description: PHP loads only PART of a page Description: I'm using Xoops. In the administration control panel, the pages in there are only partly displayed when loaded. The buttons and positioning are misplaced and messed up. When I click refresh, it gets messed up more. But it is just luck. After 4-6 refreshes, I usually get the entire page to load. Then I can continue what I'm doing. But this really bugs me because I have to sit there and click refresh all the time... By the way, it's not the xoops problem. PHP will do this to me when a BIG php file is loaded. I think it's a configuration of php.ini. Maybe there is a "time out?" or something because my server is not strong enough..? I have a P3 900 Mhz. 512 RAM. No SP1. No SP2. Apache/MYSQL configured correctly. Thank you -- Edit bug report at http://bugs.php.net/?id=35736&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=35736&r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=35736&r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=35736&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=35736&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=35736&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=35736&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=35736&r=needscript Try newer version:http://bugs.php.net/fix.php?id=35736&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=35736&r=support Expected behavior:http://bugs.php.net/fix.php?id=35736&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=35736&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=35736&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=35736&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=35736&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=35736&r=dst IIS Stability:http://bugs.php.net/fix.php?id=35736&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=35736&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=35736&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=35736&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=35736&r=mysqlcfg
#35735 [Opn->Csd]: $EGREP and $SED are not defined in configure
ID: 35735 Updated by: [EMAIL PROTECTED] -Summary: egrep not defined in ext/curl/config.m4 Reported By: selsky at columbia dot edu -Status: Open +Status: Closed -Bug Type: cURL related +Bug Type: Compile Failure Operating System: Solaris PHP Version: 4CVS-2005-12-19 (snap) New Comment: This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2005-12-19 23:19:53] selsky at columbia dot edu Description: $EGREP is not defined in ./configure since the following is missing from ext/curl/config.m4: dnl properly set EGREP for AC_EGREP_CPP later on AC_CHECK_PROG(EGREP, egrep, grep -E) AC_SUBST(EGREP) Reproduce code: --- $ ./configure --with-openssl=/opt/openssl-0.9.7i --with-curl=/opt/curl-7.11.1 Expected result: [...] checking for SSL support in libcurl... yes Actual result: -- [...] checking for SSL support in libcurl... ../../src/configure: SSL: not found no -- Edit this bug report at http://bugs.php.net/?id=35735&edit=1
#35714 [Opn->Bgs]: odbc_connect() does not timeout.
ID: 35714
Updated by: [EMAIL PROTECTED]
Reported By: ceason at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: ODBC related
Operating System: Linux
PHP Version: 5.1.1
New Comment:
You won't test, we can't fix. Bogus.
Previous Comments:
[2005-12-19 23:10:21] ceason at gmail dot com
Compiled with latest and gave POD ODBC driver a spin. Switching to POD
will require a rewrite if I understand it correctly. Will have to work
with original for now.
[2005-12-17 02:53:19] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.1-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.1-win32-latest.zip
And use the PDO ODBC driver instead.
[2005-12-16 21:13:50] ceason at gmail dot com
Description:
A php script that didn't check the odbc_connect return value entered a
state
where it did not end. The httpd server does not seem to time these
requests out
and reports the as "W" Sending Reply state. Eventually this causes
access
denial due to max_connection limit being reached. I upgraded to httpd
2.2.0 and
php 5.1.1 but the problem still occurs.
This is the timeout value from httpd.conf
#
# Timeout: The number of seconds before receives and sends time out.
#
Timeout 300
This is the timeout value from php.ini
max_execution_time = 120 ; Maximum execution time of each script,
in seconds
max_input_time = 60 ; Maximum amount of time each script may spend
parsing
request data
memory_limit = 8M ; Maximum amount of memory a script may consume
(8MB)
server-status entry:
0-0 27217 2/2/2 W 0.0032840 13.20.010.01
ceason madmax GET
/status/ras_results.php?db=bgs1&severityCB=1&facilityCB=1&b
I initially reported this as an Apache bug and received this response.
This is a bug in mod_php. If mod_php does not return the control of
execution
from the script, httpd can't do anytning. Please report this to the
PHP
Project, instead of Apache HTTP Server Project.
Reproduce code:
---
$dbconn = odbc_connect("BOGUS","username","password");
$query = "select * from footable";
while(odbc_fetch_row($result)) {
print"$result";
}
This may fail correct the 1st time. Hit refresh after this and it
should hang up.
Expected result:
Similiar error messages as below
Warning: odbc_connect() [function.odbc-connect]: SQL error: \EA, SQL
state D\$ in SQLConnect in /var/www/html/test.php on line 14
Warning: odbc_fetch_row(): supplied argument is not a valid ODBC result
resource in /var/www/html/test.php on line 16
Actual result:
--
Hang after refresh
--
Edit this bug report at http://bugs.php.net/?id=35714&edit=1
#35735 [NEW]: egrep not defined in ext/curl/config.m4
From: selsky at columbia dot edu Operating system: Solaris PHP version: 4CVS-2005-12-19 (snap) PHP Bug Type: cURL related Bug description: egrep not defined in ext/curl/config.m4 Description: $EGREP is not defined in ./configure since the following is missing from ext/curl/config.m4: dnl properly set EGREP for AC_EGREP_CPP later on AC_CHECK_PROG(EGREP, egrep, grep -E) AC_SUBST(EGREP) Reproduce code: --- $ ./configure --with-openssl=/opt/openssl-0.9.7i --with-curl=/opt/curl-7.11.1 Expected result: [...] checking for SSL support in libcurl... yes Actual result: -- [...] checking for SSL support in libcurl... ../../src/configure: SSL: not found no -- Edit bug report at http://bugs.php.net/?id=35735&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=35735&r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=35735&r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=35735&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=35735&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=35735&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=35735&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=35735&r=needscript Try newer version:http://bugs.php.net/fix.php?id=35735&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=35735&r=support Expected behavior:http://bugs.php.net/fix.php?id=35735&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=35735&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=35735&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=35735&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=35735&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=35735&r=dst IIS Stability:http://bugs.php.net/fix.php?id=35735&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=35735&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=35735&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=35735&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=35735&r=mysqlcfg
#35714 [Fbk->Opn]: odbc_connect() does not timeout.
ID: 35714
User updated by: ceason at gmail dot com
Reported By: ceason at gmail dot com
-Status: Feedback
+Status: Open
Bug Type: ODBC related
Operating System: Linux
PHP Version: 5.1.1
New Comment:
Compiled with latest and gave POD ODBC driver a spin. Switching to POD
will require a rewrite if I understand it correctly. Will have to work
with original for now.
Previous Comments:
[2005-12-17 02:53:19] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.1-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.1-win32-latest.zip
And use the PDO ODBC driver instead.
[2005-12-16 21:13:50] ceason at gmail dot com
Description:
A php script that didn't check the odbc_connect return value entered a
state
where it did not end. The httpd server does not seem to time these
requests out
and reports the as "W" Sending Reply state. Eventually this causes
access
denial due to max_connection limit being reached. I upgraded to httpd
2.2.0 and
php 5.1.1 but the problem still occurs.
This is the timeout value from httpd.conf
#
# Timeout: The number of seconds before receives and sends time out.
#
Timeout 300
This is the timeout value from php.ini
max_execution_time = 120 ; Maximum execution time of each script,
in seconds
max_input_time = 60 ; Maximum amount of time each script may spend
parsing
request data
memory_limit = 8M ; Maximum amount of memory a script may consume
(8MB)
server-status entry:
0-0 27217 2/2/2 W 0.0032840 13.20.010.01
ceason madmax GET
/status/ras_results.php?db=bgs1&severityCB=1&facilityCB=1&b
I initially reported this as an Apache bug and received this response.
This is a bug in mod_php. If mod_php does not return the control of
execution
from the script, httpd can't do anytning. Please report this to the
PHP
Project, instead of Apache HTTP Server Project.
Reproduce code:
---
$dbconn = odbc_connect("BOGUS","username","password");
$query = "select * from footable";
while(odbc_fetch_row($result)) {
print"$result";
}
This may fail correct the 1st time. Hit refresh after this and it
should hang up.
Expected result:
Similiar error messages as below
Warning: odbc_connect() [function.odbc-connect]: SQL error: \EA, SQL
state D\$ in SQLConnect in /var/www/html/test.php on line 14
Warning: odbc_fetch_row(): supplied argument is not a valid ODBC result
resource in /var/www/html/test.php on line 16
Actual result:
--
Hang after refresh
--
Edit this bug report at http://bugs.php.net/?id=35714&edit=1
#32962 [Fbk]: Installer puts php.ini in wrong location
ID: 32962 Updated by: [EMAIL PROTECTED] Reported By: ash at theleys dot net Status: Feedback Bug Type: IIS related Operating System: Windows Server 2003 PHP Version: 5.0.4 Assigned To: phildriscoll New Comment: the installer shouldn't even put anything in C:\windows or C:\winnt folders. Previous Comments: [2005-12-19 09:09:17] [EMAIL PROTECTED] Does this happen with the latest release? (5.1.1) [2005-11-07 00:01:14] [EMAIL PROTECTED] Phil, there's the feedback you asked. (given same day, but you didn't notice?) [2005-05-09 11:38:37] ash at theleys dot net Under this comment are all the environment variables, - there isn't a "win" one, but "windir" is pointing to the correct folder. - This was installed with me using a terminal services session, but that's not been a problem before. (the comp. names have been changed here for privacy) ALLUSERSPROFILE=C:\Documents and Settings\All Users APPDATA=C:\Documents and Settings\Administrator\Application Data CLIENTNAME=CHANGEDTOPROTECTSERVER ClusterLog=C:\WINDOWS\Cluster\cluster.log CommonProgramFiles=C:\Program Files\Common Files COMPUTERNAME=CHANGEDTOPROTECTSERVER ComSpec=C:\WINDOWS\system32\cmd.exe HOMEDRIVE=C: HOMEPATH=\Documents and Settings\Administrator LOGONSERVER=\\HENRYV NUMBER_OF_PROCESSORS=4 OS=Windows_NT Path=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH PROCESSOR_ARCHITECTURE=x86 PROCESSOR_IDENTIFIER=x86 Family 15 Model 2 Stepping 9, GenuineIntel PROCESSOR_LEVEL=15 PROCESSOR_REVISION=0209 ProgramFiles=C:\Program Files PROMPT=$P$G SESSIONNAME=RDP-Tcp#1 SystemDrive=C: SystemRoot=C:\WINDOWS TEMP=C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\1 TMP=C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\1 USERDOMAIN=HENRYV USERNAME=Administrator USERPROFILE=C:\Documents and Settings\Administrator windir=C:\WINDOWS [2005-05-09 11:01:08] [EMAIL PROTECTED] I don't have Windows Server 2003, and I can't reproduce the problem on W2K Advanced Server (the only Windows machine I have). Can you tell me what the value of the WIN environment variable is when you are logged in as administrator? Thanks [2005-05-07 06:14:01] [EMAIL PROTECTED] Assigning to the author of the installer. 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/32962 -- Edit this bug report at http://bugs.php.net/?id=32962&edit=1
#35733 [Bgs]: preg_replace() distroys $GLOBALS
ID: 35733
User updated by: gerhard at tinned-software dot net
Reported By: gerhard at tinned-software dot net
Status: Bogus
Bug Type: PCRE related
Operating System: WinXP/Linux
PHP Version: 5.1.1
New Comment:
Way should $entry be a reference??
And when $entry is a reference and this is the correct behaviour, way
is it then working with ereg_replace function???
If it is only a reference, how to make a real copy of it??
Previous Comments:
[2005-12-19 16:29:47] [EMAIL PROTECTED]
>$value contains the content of the variable and is copied to $entry
.. and since $entry is a reference, $value is a reference too.
It doesn't work in PHP4 either.
Add var_dump($GLOBALS); at the end of your code and you'll see it.
It's expected.
[2005-12-19 16:27:58] [EMAIL PROTECTED]
If it worked in PHP 4 it's a bug there. Don't play around with GLOBALS
like that. It's expected behaviour to work unexpectedly.
[2005-12-19 16:21:56] gerhard at tinned-software dot net
with preg_replace i only remove newlines from a string which contains
the content of the variable! $value contains the content of the
variable and is copied to $entry ... only $entry is changed not the
$value which is used to check if it is an array and which is aslo used
to call the function recursive!
foreach($array as $key => $value){
$entry = $value;
how can this damage the $GLOBALS??? ... and if this is not a bug, way
it is working with PHP4.x???
[2005-12-19 15:12:47] [EMAIL PROTECTED]
$GLOBALS contains reference to itself.
In your code you're effectively converting all the elements to strings
with preg_replace(), so GLOBALS itself becomes string too.
Not a bug.
[2005-12-19 15:01:19] gerhard at tinned-software dot net
Description:
PHP 5 PCRE Bug!?
We have in our program a function to log all $GLOBALS variables. This
function
calls itself recursive to log all variables of a array and all its
sub-arrays.
This function is working fine in PHP 4.0.1 and up to 4.3.10 (the
highest of our
test configuration.)
Since PHP5 (different versions) it was not working anymore when you
call the function with $GLOBALS as
parameter. The logfile contained only one line ...
|-> GLOBALS = Array
After some hours i go it working by replacing the preg_replace()
function with
the ereg_replace() function.
The problem shows as follows:
After calling function preg_replace() the $GLOBALS array contails only
1 element
which is $GLOBALS. (i cheched it with count($GLOBALS);) after that the
check
is_array() is always returning "1" instead of true or false.
after replacing the ...
preg_replace("/\r*\n/", " ", $entry);
... with ...
ereg_replace("\n", " ", $entry);
ereg_replace("\r", " ", $entry);
... the function is working without problems. PHP must be configured
correctly
because this function preg_replace() is used very often in our program.
This
function is also workinf fine when called with any other array. Only
when
$GLOBALS is used to call this function it shows this behaviour.
We checked this behaviour with different PHP4.x (everything was
working) and some versions of PHP5 (on all the same problem - last
tested version 5.1.1). And also on different OS (Linux, MacOSX, WinXP,
Win2000).
Reproduce code:
---
$value){
$entry = $value;
$entry = preg_replace("/\r*\n/", " ", $entry);
$entry2 = "$level_space|-> $key = $entry\n";
$FILE = fopen("array.log", "a");
fwrite($FILE, $entry2);
fclose($FILE);
echo is_array($value);
if(is_array($value)){
if($key == "GLOBALS"){ continue; }
array_log($value, $level + 1);
}
}
}
?>
Expected result:
Logfile with PHP 5.1.1:
|-> GLOBALS = Array
Logfile with 4.x.x (as it should look like):
|-> HTTP_ENV_VARS = Array
|-> DBROOT = /dev/null
|-> BOOT_FILE = /boot/vmlinuz
|-> HOSTNAME = mail
|-> CONSOLE = /dev/console
|-> LD_LIBRARY_PATH = :/lib
.
.
.
|-> HTTP_POST_FILES = Array
|-> GLOBALS = Array
|-> GATEWAY_INTERFACE = CGI/1.1
|-> SERVER_PROTOCOL = HTTP/1.0
|-> REQUEST_METHOD = GET
|-> QUERY_STRING =
.
.
.
Actual result:
--
Replace ...
$entry = preg_replace("/\r*\n/", " ", $entry);
... With ...
$entry = ereg_replace("\r", "", $entry);
$entry = ereg_replace("\n", " ", $entry);
After changing it to ereg_replace() it is working with PHP4.0.1, 4.3.10
and 5.1.1
--
Edit this bug report at http://bugs.php.net/?id=35733&edit=1
#35734 [Csd->Bgs]: RecursiveIteratorIterator constructor fails to recognize mode constants
ID: 35734
Updated by: [EMAIL PROTECTED]
Reported By: dpantel at gmail dot com
-Status: Closed
+Status: Bogus
Bug Type: SPL related
Operating System: RHES (linux 2.4.21-37)
PHP Version: 5.1.1
Previous Comments:
[2005-12-19 19:29:21] dpantel at gmail dot com
My appologies. I have recompiled PHP 5.1.1 and
`RecursiveIteratorIterator::SELF_FIRST` now works.
[2005-12-19 16:38:38] dpantel at gmail dot com
If you take the time to read the bug report, you will notice that I
have tried using `RecursiveIteratorIterator::SELF_FIRST` without
success.
[2005-12-19 16:31:59] [EMAIL PROTECTED]
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
Those are class constants now:
RecursiveIteratorIterator::SELF_FIRST
[2005-12-19 16:27:39] dpantel at gmail dot com
Description:
RecursiveIteratorIterator constructor fails to recognize mode
constants.
The constructor works fine when passed only a RecursiveIterator object.
It also functions correctly if passed a RecursiveIterator object and an
integer (0,1,2, etc) as the second (mode) argument. However, if one
attempts to pass a documented constant keyword (RIT_SELF_FIRST or
SELF_FIRST), the constructor fails.
Note: different documentations show different constant definitions
(RIT_SELF_FIRST vs SELF_FIRST). I have tried both, and neither one
works.
Reproduce code:
---
class Rit implements RecursiveIterator {...}
$test = new Rit();
//work fine
$rii = new RecursiveIteratorIterator($test);
$rii = new RecursiveIteratorIterator($test, 1);
//do not work
$rii = new RecursiveIteratorIterator($test, RIT_SELF_FIRST);
$rii = new RecursiveIteratorIterator($test, SELF_FIRST);
//even tried this, with no avail
$rii = new RecursiveIteratorIterator($test,
RecursiveIteratorIterator::RIT_SELF_FIRST);
$rii = new RecursiveIteratorIterator($test,
RecursiveIteratorIterator::SELF_FIRST);
Expected result:
A RecursiveIteratorIterator object
Actual result:
--
Notice: Use of undefined constant RIT_SELF_FIRST - assumed
'RIT_SELF_FIRST' in /www/rit.class.php on line 276
(or Notice: Use of undefined constant SELF_FIRST - assumed 'SELF_FIRST'
in /www/rit.class.php on line 276)
Fatal error: Uncaught exception 'InvalidArgumentException' with message
'An instance of RecursiveIterator or IteratorAggregate creating it is
required' in /www/rit.class.php:276 Stack trace: #0
/www/rit.class.php(276):
RecursiveIteratorIterator->__construct(Object(treeIterator),
'RIT_SELF_FIRST') ...
--
Edit this bug report at http://bugs.php.net/?id=35734&edit=1
#35734 [Bgs->Csd]: RecursiveIteratorIterator constructor fails to recognize mode constants
ID: 35734
User updated by: dpantel at gmail dot com
Reported By: dpantel at gmail dot com
-Status: Bogus
+Status: Closed
Bug Type: SPL related
Operating System: RHES (linux 2.4.21-37)
PHP Version: 5.1.1
New Comment:
My appologies. I have recompiled PHP 5.1.1 and
`RecursiveIteratorIterator::SELF_FIRST` now works.
Previous Comments:
[2005-12-19 16:38:38] dpantel at gmail dot com
If you take the time to read the bug report, you will notice that I
have tried using `RecursiveIteratorIterator::SELF_FIRST` without
success.
[2005-12-19 16:31:59] [EMAIL PROTECTED]
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
Those are class constants now:
RecursiveIteratorIterator::SELF_FIRST
[2005-12-19 16:27:39] dpantel at gmail dot com
Description:
RecursiveIteratorIterator constructor fails to recognize mode
constants.
The constructor works fine when passed only a RecursiveIterator object.
It also functions correctly if passed a RecursiveIterator object and an
integer (0,1,2, etc) as the second (mode) argument. However, if one
attempts to pass a documented constant keyword (RIT_SELF_FIRST or
SELF_FIRST), the constructor fails.
Note: different documentations show different constant definitions
(RIT_SELF_FIRST vs SELF_FIRST). I have tried both, and neither one
works.
Reproduce code:
---
class Rit implements RecursiveIterator {...}
$test = new Rit();
//work fine
$rii = new RecursiveIteratorIterator($test);
$rii = new RecursiveIteratorIterator($test, 1);
//do not work
$rii = new RecursiveIteratorIterator($test, RIT_SELF_FIRST);
$rii = new RecursiveIteratorIterator($test, SELF_FIRST);
//even tried this, with no avail
$rii = new RecursiveIteratorIterator($test,
RecursiveIteratorIterator::RIT_SELF_FIRST);
$rii = new RecursiveIteratorIterator($test,
RecursiveIteratorIterator::SELF_FIRST);
Expected result:
A RecursiveIteratorIterator object
Actual result:
--
Notice: Use of undefined constant RIT_SELF_FIRST - assumed
'RIT_SELF_FIRST' in /www/rit.class.php on line 276
(or Notice: Use of undefined constant SELF_FIRST - assumed 'SELF_FIRST'
in /www/rit.class.php on line 276)
Fatal error: Uncaught exception 'InvalidArgumentException' with message
'An instance of RecursiveIterator or IteratorAggregate creating it is
required' in /www/rit.class.php:276 Stack trace: #0
/www/rit.class.php(276):
RecursiveIteratorIterator->__construct(Object(treeIterator),
'RIT_SELF_FIRST') ...
--
Edit this bug report at http://bugs.php.net/?id=35734&edit=1
#34047 [Com]: When compile php cannot generate libphp5.so
ID: 34047 Comment by: till at klimpong dot com Reported By: calvinscy at hotmail dot com Status: No Feedback Bug Type: Compile Failure Operating System: Solaris 8 PHP Version: 5.0.4 New Comment: I'm having the same issue (it didn't build libphp5.so) with the 5.1.1 when I downloaded it from the website. My OS: FreeBSD 4.11-stable My libtool is: 1.5.x Using the latest snapshot solves this problem, but I am wondering why. Happy to provide more feedback when asked. :-) Previous Comments: [2005-08-28 21:26:21] rob at silverarcher dot com sunfreeware doesn't work either. I'm using Fedora Core 4 and cannot get this one part to compile. [2005-08-28 21:12:45] rob at silverarcher dot com The problem still seems to be occurring. php-5.0.4 and php- latest both will not compile the libphp5.so. I'm hoping sunfreeware.com can help... [2005-08-17 01:00:03] 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". [2005-08-09 10:21:22] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2005-08-09 09:47:08] calvinscy at hotmail dot com Description: When compiling the php5.0.4 download from your site, it cannot generate a file called libphp5.so. But if I download php-5.0.4.tar.gz from sunfreeware.com it can. After "make install" completed I can see the libphp5.so created under apache2/modules directory. I try the php4 from your site as well, it cannot generate libphp5.so too! -- Edit this bug report at http://bugs.php.net/?id=34047&edit=1
#29840 [Opn->Asn]: is_executable does not honor the safe_mode_exec_dir setting
ID: 29840 Updated by: [EMAIL PROTECTED] Reported By: markus at cultcom dot de -Status: Open +Status: Assigned Bug Type: Filesystem function related Operating System: * PHP Version: 5CVS, 4CVS (2005-01-04) Assigned To: tony2001 New Comment: tony2001: 2 words for you: Just commit! :) Previous Comments: [2005-12-05 11:17:08] [EMAIL PROTECTED] Any news on this? Would appreciate this patch in PHP4 and PHP5 [2005-08-12 01:00:33] [EMAIL PROTECTED] Please try this patch: http://tony2001.phpclub.net/dev/tmp/bugs_29840_31618.diff (with the latest snapshot/CVS). [2004-12-12 11:36:05] [EMAIL PROTECTED] Jani, I sent a patch for this problem to Wez long ago. The problem is that is_executable() indeed doesn't respect safe_mode_exec_dir as it should, so I'm assigning this to Wez. [2004-12-12 02:07:16] [EMAIL PROTECTED] It works just fine. (it returns false always when in safe-mode..) [2004-08-25 18:06:12] markus at cultcom dot de Description: Seems to be a common problem nobody complains about... "is_executable()" does not work in safe_mode! Some PHP-Projects check for sendmail using this function and don't work in safe_mode even if sendmail acutally IS executable (i.e. PEAR: Mail.php). is_executable() should at least honor the safe_mode_exec_dir directive! Reproduce code: --- Try with PHP/CGI and suexec + safe_mode where example-UID != sendmail-UID Expected result: true, what else? Actual result: -- false. -- Edit this bug report at http://bugs.php.net/?id=29840&edit=1
#35691 [Opn->Asn]: Can't change to another drive letter using chdir()
ID: 35691
Updated by: [EMAIL PROTECTED]
Reported By: ejwaibel at gmail dot com
-Status: Open
+Status: Assigned
Bug Type: *Directory/Filesystem functions
Operating System: Windows 2003
-PHP Version: 5.1.1
+PHP Version: 5CVS-2005-12-19 (snap)
-Assigned To:
+Assigned To: nlopess
Previous Comments:
[2005-12-19 17:41:10] [EMAIL PROTECTED]
So, this is only happening with attached drive on Windows 2003. I can
only think of a bug in GetLongPathName().
I'll install windows 2003 server somewhere to test.
[2005-12-19 01:42:04] erik dot waibel at cubic dot com
This is what I get when running the code with an existing drive (such
as C:)
Files in current directory...
Array ( [0] => TCdetails.php [1] => TCgetdata.php [2] =>
TCgetversion.php [3] => TCmanual.php [4] => TCpreview.php [5] =>
TCprocess.php [6] => TCsearch.php [7] => changes.php [8] =>
checklist.php [9] => details.php [10] => footer.php [11] => getarq.php
[12] => getdata.php [13] => help.php [14] => hints.php [15] =>
import.php [16] => login.php [17] => manual.php [18] => modules.php
[19] => password.php [20] => phpinfo.php [21] => process.php [22] =>
search.php [23] => srnform_windows.php [24] => stscr.php [25] =>
user.php )
string(35) "d:\scmtools\test\ctssrn-enhancement" CWD:
bool(true) Change dir:
string(3) "C:\" CWD:
Files in CWD...
Array ( [0] => AUTOEXEC.BAT [1] => CONFIG.SYS [2] => Documents and
Settings [3] => IO.SYS [4] => Inetpub [5] => MSDOS.SYS [6] =>
NTDETECT.COM [7] => PHP [8] => Perl [9] => Program Files [10] =>
RECYCLER [11] => System Volume Information [12] => WINDOWS [13] =>
boot.ini [14] => dsn [15] => dsn.dir [16] => dsn.pag [17] => mvfslogs
[18] => ntldr [19] => pagefile.sys [20] => temp.log [21] => wmpub )
This is what I get when I change to the drive that is being 'subst':
Files in current directory...
Array ( [0] => TCdetails.php [1] => TCgetdata.php [2] =>
TCgetversion.php [3] => TCmanual.php [4] => TCpreview.php [5] =>
TCprocess.php [6] => TCsearch.php [7] => changes.php [8] =>
checklist.php [9] => details.php [10] => footer.php [11] => getarq.php
[12] => getdata.php [13] => help.php [14] => hints.php [15] =>
import.php [16] => login.php [17] => manual.php [18] => modules.php
[19] => password.php [20] => phpinfo.php [21] => process.php [22] =>
search.php [23] => srnform_windows.php [24] => stscr.php [25] =>
user.php )
string(35) "d:\scmtools\test\ctssrn-enhancement" CWD:
bool(false) Change dir:
string(35) "d:\scmtools\test\ctssrn-enhancement" CWD:
Files in CWD...
Array ( [0] => TCdetails.php [1] => TCgetdata.php [2] =>
TCgetversion.php [3] => TCmanual.php [4] => TCpreview.php [5] =>
TCprocess.php [6] => TCsearch.php [7] => cc-get-modules.exe [8] =>
cc-import.exe [9] => changes.php [10] => checklist.php [11] =>
details.php [12] => error_log.log [13] => footer.php [14] => getarq.php
[15] => getdata.php [16] => help.php [17] => hints.php [18] =>
import.php [19] => login.php [20] => manual.php [21] => modules.php
[22] => password.php [23] => phpinfo.php [24] => process.php [25] =>
search.php [26] => srnform_windows.php [27] => stscr.php [28] =>
user.php )
[2005-12-19 00:14:44] [EMAIL PROTECTED]
I've also tested with networked drives and it works fine.
can you please test with a simple script like:
Please include all error messages printed by PHP.
[2005-12-16 16:41:50] erik dot waibel at cubic dot com
I updated my PHP version to the Windows .zip file that you included,
but that still did not work. We are using a Windows NT 5.2 build 3790
machine (it's a Windows NT server). I actually just checked and it
seems like I can change to the "C:" drive, but what I forgot to mention
earlier, here is another piece of my code that is used to "subst" the Q:
drive for a directory that exists on another drive.
$subst = exec("subst $substDrive M:\\$sessionView", $substOutput);
$currentDir = getcwd();
$changeTo = "$substDrive\\sdadmin";
chdir("$changeTo") || die("Can't change
location to: $changeTo.");
The reason I'm doing this is because of our Source Control program
"ClearCase" that we use. Can you let me know if there is another way I
should do this?
[2005-12-16 14:06:53] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.1-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.1-win32-latest.zip
Sorry, but I can't reproduce this behaviour. I'm able to chdir()
between drives with PHP 5.1.2 from snaps.php.net and with PHP 6 built
by me.
I've a
#35730 [Asn->Fbk]: mssql didn't use the right character encoding in freetds.conf
ID: 35730 Updated by: [EMAIL PROTECTED] Reported By: liang at saga-city dot com -Status: Assigned +Status: Feedback Bug Type: MSSQL related Operating System: FreeBSD PHP Version: 5.1.1 Assigned To: fmk New Comment: Are you absolutely sure you're linking PHP with the same freetds library as you did with PHP 4? Previous Comments: [2005-12-19 05:48:08] liang at saga-city dot com we have been testing the mssql extension both in PHP4 and PHP5.1.1, " with the same freetds.conf " tds version = 8.0 client charset = BIG-5 In php4, it works fine, but not in php5.1.1 ( our old system uses php5.0.3 also work fine in the "same" freetds.conf ) [2005-12-19 03:27:06] [EMAIL PROTECTED] All encoding is handled by freetds in both PHP4 and PHP5. Execpt for internal PHP stuff the mssql extension is the same for PHP4 and PHP5. You need to change the encoding in freetds.conf. [2005-12-19 02:29:00] liang at saga-city dot com Description: php5 mssql didn't use character encoding specify in freetds.conf ( alwasy use ISO-8559-1 , seen in freetds.log ) switch to php4 , everythings works fine -- Edit this bug report at http://bugs.php.net/?id=35730&edit=1
#32503 [Fbk->Opn]: fopen() in cwd: filename must start with ./ under safe mode
ID: 32503 User updated by: Bjorn dot Wiberg at its dot uu dot se Reported By: Bjorn dot Wiberg at its dot uu dot se -Status: Feedback +Status: Open Bug Type: Safe Mode/open_basedir Operating System: IBM AIX 5.2.0.0 ML5 -PHP Version: 5CVS-2005-07-05 +PHP Version: 5.1.1 New Comment: Hi sniper! Just wanted to tell you that for 5.1.1, the following holds: If the path to the file is not listable (r flag) all the way, one gets the following message: Warning: fopen(): open_basedir restriction in effect. File(a.txt) is not within the allowed path(s): (.:/apache/php/lib/php/:/apache/htdocs/bwiberg/) in /apache/htdocs/bwiberg/test/safemode/write.php on line 5 Warning: fopen(a.txt): failed to open stream: Not owner in /apache/htdocs/bwiberg/test/safemode/write.php on line 5 The same error occurs until one makes sure that the path all the way to the file is listable (r flag). Then, with the path all the way to the file listable (r flag), one gets, with "a.txt" and no existing file: /apache/htdocs/bwiberg/test/safemode Warning: fopen(): Unable to access a.txt in /apache/htdocs/bwiberg/test/safemode/write.php on line 5 Warning: fopen(a.txt): failed to open stream: No such file or directory in /apache/htdocs/bwiberg/test/safemode/write.php on line 5 However, "./a.txt" and no existing file works fine. With "a.txt" and the file already existing, things work just fine. With "./a.txt" and the file already existing, things work just fine. Would it be OK to wait for 5.1.2, or have things related to this actually changed in the latest snapshot? (I just recompiled and installed 5.1.1, awaiting some possible input on or fixes to another bug, so I hope to recompile again sometime early next year.) Wishing you a Merry Christmas and a Happy New Year, and for putting up with me and my AIX troubles. :-) Best regards, Björn Previous Comments: [2005-12-19 09:11:23] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip [2005-07-05 10:21:38] Bjorn dot Wiberg at its dot uu dot se (Thanks for fixing the mpm_common crash, that problem is gone now.) With #define HAVE_BROKEN_GETCWD 1 in php_config.h, and having made sure that the path up to the directory where the file is to be created has sufficient permissions, I still get the same error: /apache/htdocs/bwiberg/test/safemode Warning: fopen(): Unable to access a.txt in /apache/htdocs/bwiberg/test/safemode/write.php on line 5 Warning: fopen(a.txt): failed to open stream: No such file or directory in /apache/htdocs/bwiberg/test/safemode/write.php on line 5 Having the read (r) permission off for the "test" directory along the way: Warning: fopen(): open_basedir restriction in effect. File(a.txt) is not within the allowed path(s): (.:/apache/php/lib/php/:/apache/htdocs/bwiberg/) in /apache/htdocs/bwiberg/test/safemode/write.php on line 5 Warning: fopen(a.txt): failed to open stream: Not owner in /apache/htdocs/bwiberg/test/safemode/write.php on line 5 Best regards, Björn [2005-05-09 14:15:53] Bjorn dot Wiberg at its dot uu dot se Hi again! I just tried the #define HAVE_BROKEN_GETCWD 1 trick from http://bugs.php.net/bug.php?id=32501, with PHP 5.0.4 (the "fixed" version) but that didn't help in this regard. I thought I would mention this. Best regards, Björn [2005-04-05 09:28:28] Bjorn dot Wiberg at its dot uu dot se Hi Tony! Thank you for your feedback! I'm afraid that absolute paths aren't a very viable solution to this, as that probably would break too many scripts, expecting it to be possible to "just" save a file to the current directory. Is the "PHP realpath hack" supposed to handle these kind of problems on AIX? Please let me know if I can help in any way! Best regards, Björn [2005-04-04 17:11:05] [EMAIL PROTECTED] Right, this is somehow concerned with broken realpath() on AIX. The problem is that we end up with relative path in php_checkuid_ex() function and it fails to check permissions for the directory. Of course, the easiest solution is to use absolute paths everywhere. 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/32503 -- Edit this bug report at http://bugs.php.net/?id=32503&edit=1
#35691 [Fbk->Opn]: Can't change to another drive letter using chdir()
ID: 35691
Updated by: [EMAIL PROTECTED]
Reported By: ejwaibel at gmail dot com
-Status: Feedback
+Status: Open
Bug Type: *Directory/Filesystem functions
-Operating System: Windows
+Operating System: Windows 2003
PHP Version: 5.1.1
New Comment:
So, this is only happening with attached drive on Windows 2003. I can
only think of a bug in GetLongPathName().
I'll install windows 2003 server somewhere to test.
Previous Comments:
[2005-12-19 01:42:04] erik dot waibel at cubic dot com
This is what I get when running the code with an existing drive (such
as C:)
Files in current directory...
Array ( [0] => TCdetails.php [1] => TCgetdata.php [2] =>
TCgetversion.php [3] => TCmanual.php [4] => TCpreview.php [5] =>
TCprocess.php [6] => TCsearch.php [7] => changes.php [8] =>
checklist.php [9] => details.php [10] => footer.php [11] => getarq.php
[12] => getdata.php [13] => help.php [14] => hints.php [15] =>
import.php [16] => login.php [17] => manual.php [18] => modules.php
[19] => password.php [20] => phpinfo.php [21] => process.php [22] =>
search.php [23] => srnform_windows.php [24] => stscr.php [25] =>
user.php )
string(35) "d:\scmtools\test\ctssrn-enhancement" CWD:
bool(true) Change dir:
string(3) "C:\" CWD:
Files in CWD...
Array ( [0] => AUTOEXEC.BAT [1] => CONFIG.SYS [2] => Documents and
Settings [3] => IO.SYS [4] => Inetpub [5] => MSDOS.SYS [6] =>
NTDETECT.COM [7] => PHP [8] => Perl [9] => Program Files [10] =>
RECYCLER [11] => System Volume Information [12] => WINDOWS [13] =>
boot.ini [14] => dsn [15] => dsn.dir [16] => dsn.pag [17] => mvfslogs
[18] => ntldr [19] => pagefile.sys [20] => temp.log [21] => wmpub )
This is what I get when I change to the drive that is being 'subst':
Files in current directory...
Array ( [0] => TCdetails.php [1] => TCgetdata.php [2] =>
TCgetversion.php [3] => TCmanual.php [4] => TCpreview.php [5] =>
TCprocess.php [6] => TCsearch.php [7] => changes.php [8] =>
checklist.php [9] => details.php [10] => footer.php [11] => getarq.php
[12] => getdata.php [13] => help.php [14] => hints.php [15] =>
import.php [16] => login.php [17] => manual.php [18] => modules.php
[19] => password.php [20] => phpinfo.php [21] => process.php [22] =>
search.php [23] => srnform_windows.php [24] => stscr.php [25] =>
user.php )
string(35) "d:\scmtools\test\ctssrn-enhancement" CWD:
bool(false) Change dir:
string(35) "d:\scmtools\test\ctssrn-enhancement" CWD:
Files in CWD...
Array ( [0] => TCdetails.php [1] => TCgetdata.php [2] =>
TCgetversion.php [3] => TCmanual.php [4] => TCpreview.php [5] =>
TCprocess.php [6] => TCsearch.php [7] => cc-get-modules.exe [8] =>
cc-import.exe [9] => changes.php [10] => checklist.php [11] =>
details.php [12] => error_log.log [13] => footer.php [14] => getarq.php
[15] => getdata.php [16] => help.php [17] => hints.php [18] =>
import.php [19] => login.php [20] => manual.php [21] => modules.php
[22] => password.php [23] => phpinfo.php [24] => process.php [25] =>
search.php [26] => srnform_windows.php [27] => stscr.php [28] =>
user.php )
[2005-12-19 00:14:44] [EMAIL PROTECTED]
I've also tested with networked drives and it works fine.
can you please test with a simple script like:
Please include all error messages printed by PHP.
[2005-12-16 16:41:50] erik dot waibel at cubic dot com
I updated my PHP version to the Windows .zip file that you included,
but that still did not work. We are using a Windows NT 5.2 build 3790
machine (it's a Windows NT server). I actually just checked and it
seems like I can change to the "C:" drive, but what I forgot to mention
earlier, here is another piece of my code that is used to "subst" the Q:
drive for a directory that exists on another drive.
$subst = exec("subst $substDrive M:\\$sessionView", $substOutput);
$currentDir = getcwd();
$changeTo = "$substDrive\\sdadmin";
chdir("$changeTo") || die("Can't change
location to: $changeTo.");
The reason I'm doing this is because of our Source Control program
"ClearCase" that we use. Can you let me know if there is another way I
should do this?
[2005-12-16 14:06:53] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.1-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.1-win32-latest.zip
Sorry, but I can't reproduce this behaviour. I'm able to chdir()
between drives with PHP 5.1.2 from snaps.php.net and with PHP 6 built
by me.
I've also tested on two different machines with windows XP.
And what is your windows version?
#34482 [Com]: LDAP Searches cause Access Violation when connecting via LDAPS
ID: 34482 Comment by: pbarabe at paddyworks dot com Reported By: zbowden at vt dot edu Status: Assigned Bug Type: LDAP related Operating System: Windows 2003 PHP Version: 5CVS-2005-09-12 (snap) Assigned To: edink New Comment: I've been experiencing essentially the same problems as zbowden when upgrading from PHP 5.0.4 to 5.1.1 on Win2003/Apache 2.0.49/ISAPI. ldap_bind() breaks (returns message "Can't contact LDAP server". Replacing libeay32.dll and ssleay32.dll with those distributed with 5.1.1 does not fix the problem, though I can confirm that ldap_bind in PHP 5.0.4 still works with the new dlls. Previous Comments: [2005-11-28 22:13:17] zbowden at vt dot edu just some additional information: if I try to use the ldap_start_tls() function I now get "Unable to start TLS: Not Supported" maybe an error in the build process (i.e. not turning on TLS and or LDAPS)? [2005-11-28 20:22:56] zbowden at vt dot edu Just a brief update: in 5.1.1 LDAPS URI's still don't work; the workaround I had for 5.0.5 doesn't work any longer either as we saw in the recent snapshots. I no longer get an access violation, however I cannot get a connection. Bbuie is correct, the problem doesn't actually present itself on the ldap_connect function, rather on the subsequent bind, search, etc. I think the problem may be in the newer versions of openssl. What's leading me to this is that when I do a filemon trace as I execute a php script I can see it reading the conf file however it will never try to read or create the c:\.rnd file like it used to .. according to the openssl changelog I see this: "In versions up to 0.9.6, RAND_file_name() resorted to file ".rnd" in the current directory if neither $RANDFILE nor $HOME was set. RAND_file_name() in 0.9.6a returned NULL in this case. This has caused some confusion to Windows users who haven't defined $HOME.Thus RAND_file_name() is changed again: e_os.h can define a DEFAULT_HOME, which will be used if $HOME is not set. For Windows, we use "C:"; on other platforms, we still require environment variables. " I've tried setting a RANDFILE env variable and that didn't help; I've also tried setting the TLS_RANDFILE in the ldap.conf file but that didn't seem to have any effect either. [2005-10-31 20:30:06] zbowden at vt dot edu Just an additional idea/comment. If I go to 5.0.5 and replace the libeay32.dll and ssleay32.dll files with the ones included with the 5.0.4 release everything works fine. [2005-10-27 17:25:23] zbowden at vt dot edu tried the latest snapshot; I not longer get the access violation, however I cannot connect to any ldap server via LDAPS URI (says it can't contact server). I did use ntfilemon to make sure the ldap.conf (and ldaprc) files were being read and they are. Not sure where the problem is though? I rolled back to the release version of 5.0.4 just to be sure it would still work and I can connect & bind to the ldap servers via LDAPS (& start_tls). [2005-10-24 01:14:59] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.0-win32-latest.zip 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/34482 -- Edit this bug report at http://bugs.php.net/?id=34482&edit=1
#35734 [Bgs]: RecursiveIteratorIterator constructor fails to recognize mode constants
ID: 35734
User updated by: dpantel at gmail dot com
Reported By: dpantel at gmail dot com
Status: Bogus
Bug Type: SPL related
Operating System: RHES (linux 2.4.21-37)
PHP Version: 5.1.1
New Comment:
If you take the time to read the bug report, you will notice that I
have tried using `RecursiveIteratorIterator::SELF_FIRST` without
success.
Previous Comments:
[2005-12-19 16:31:59] [EMAIL PROTECTED]
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
Those are class constants now:
RecursiveIteratorIterator::SELF_FIRST
[2005-12-19 16:27:39] dpantel at gmail dot com
Description:
RecursiveIteratorIterator constructor fails to recognize mode
constants.
The constructor works fine when passed only a RecursiveIterator object.
It also functions correctly if passed a RecursiveIterator object and an
integer (0,1,2, etc) as the second (mode) argument. However, if one
attempts to pass a documented constant keyword (RIT_SELF_FIRST or
SELF_FIRST), the constructor fails.
Note: different documentations show different constant definitions
(RIT_SELF_FIRST vs SELF_FIRST). I have tried both, and neither one
works.
Reproduce code:
---
class Rit implements RecursiveIterator {...}
$test = new Rit();
//work fine
$rii = new RecursiveIteratorIterator($test);
$rii = new RecursiveIteratorIterator($test, 1);
//do not work
$rii = new RecursiveIteratorIterator($test, RIT_SELF_FIRST);
$rii = new RecursiveIteratorIterator($test, SELF_FIRST);
//even tried this, with no avail
$rii = new RecursiveIteratorIterator($test,
RecursiveIteratorIterator::RIT_SELF_FIRST);
$rii = new RecursiveIteratorIterator($test,
RecursiveIteratorIterator::SELF_FIRST);
Expected result:
A RecursiveIteratorIterator object
Actual result:
--
Notice: Use of undefined constant RIT_SELF_FIRST - assumed
'RIT_SELF_FIRST' in /www/rit.class.php on line 276
(or Notice: Use of undefined constant SELF_FIRST - assumed 'SELF_FIRST'
in /www/rit.class.php on line 276)
Fatal error: Uncaught exception 'InvalidArgumentException' with message
'An instance of RecursiveIterator or IteratorAggregate creating it is
required' in /www/rit.class.php:276 Stack trace: #0
/www/rit.class.php(276):
RecursiveIteratorIterator->__construct(Object(treeIterator),
'RIT_SELF_FIRST') ...
--
Edit this bug report at http://bugs.php.net/?id=35734&edit=1
#35734 [Opn->Bgs]: RecursiveIteratorIterator constructor fails to recognize mode constants
ID: 35734
Updated by: [EMAIL PROTECTED]
Reported By: dpantel at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: SPL related
Operating System: RHES (linux 2.4.21-37)
PHP Version: 5.1.1
New Comment:
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
Those are class constants now:
RecursiveIteratorIterator::SELF_FIRST
Previous Comments:
[2005-12-19 16:27:39] dpantel at gmail dot com
Description:
RecursiveIteratorIterator constructor fails to recognize mode
constants.
The constructor works fine when passed only a RecursiveIterator object.
It also functions correctly if passed a RecursiveIterator object and an
integer (0,1,2, etc) as the second (mode) argument. However, if one
attempts to pass a documented constant keyword (RIT_SELF_FIRST or
SELF_FIRST), the constructor fails.
Note: different documentations show different constant definitions
(RIT_SELF_FIRST vs SELF_FIRST). I have tried both, and neither one
works.
Reproduce code:
---
class Rit implements RecursiveIterator {...}
$test = new Rit();
//work fine
$rii = new RecursiveIteratorIterator($test);
$rii = new RecursiveIteratorIterator($test, 1);
//do not work
$rii = new RecursiveIteratorIterator($test, RIT_SELF_FIRST);
$rii = new RecursiveIteratorIterator($test, SELF_FIRST);
//even tried this, with no avail
$rii = new RecursiveIteratorIterator($test,
RecursiveIteratorIterator::RIT_SELF_FIRST);
$rii = new RecursiveIteratorIterator($test,
RecursiveIteratorIterator::SELF_FIRST);
Expected result:
A RecursiveIteratorIterator object
Actual result:
--
Notice: Use of undefined constant RIT_SELF_FIRST - assumed
'RIT_SELF_FIRST' in /www/rit.class.php on line 276
(or Notice: Use of undefined constant SELF_FIRST - assumed 'SELF_FIRST'
in /www/rit.class.php on line 276)
Fatal error: Uncaught exception 'InvalidArgumentException' with message
'An instance of RecursiveIterator or IteratorAggregate creating it is
required' in /www/rit.class.php:276 Stack trace: #0
/www/rit.class.php(276):
RecursiveIteratorIterator->__construct(Object(treeIterator),
'RIT_SELF_FIRST') ...
--
Edit this bug report at http://bugs.php.net/?id=35734&edit=1
#35733 [Bgs]: preg_replace() distroys $GLOBALS
ID: 35733
Updated by: [EMAIL PROTECTED]
Reported By: gerhard at tinned-software dot net
Status: Bogus
Bug Type: PCRE related
Operating System: WinXP/Linux
PHP Version: 5.1.1
New Comment:
>$value contains the content of the variable and is copied to $entry
.. and since $entry is a reference, $value is a reference too.
It doesn't work in PHP4 either.
Add var_dump($GLOBALS); at the end of your code and you'll see it.
It's expected.
Previous Comments:
[2005-12-19 16:27:58] [EMAIL PROTECTED]
If it worked in PHP 4 it's a bug there. Don't play around with GLOBALS
like that. It's expected behaviour to work unexpectedly.
[2005-12-19 16:21:56] gerhard at tinned-software dot net
with preg_replace i only remove newlines from a string which contains
the content of the variable! $value contains the content of the
variable and is copied to $entry ... only $entry is changed not the
$value which is used to check if it is an array and which is aslo used
to call the function recursive!
foreach($array as $key => $value){
$entry = $value;
how can this damage the $GLOBALS??? ... and if this is not a bug, way
it is working with PHP4.x???
[2005-12-19 15:12:47] [EMAIL PROTECTED]
$GLOBALS contains reference to itself.
In your code you're effectively converting all the elements to strings
with preg_replace(), so GLOBALS itself becomes string too.
Not a bug.
[2005-12-19 15:01:19] gerhard at tinned-software dot net
Description:
PHP 5 PCRE Bug!?
We have in our program a function to log all $GLOBALS variables. This
function
calls itself recursive to log all variables of a array and all its
sub-arrays.
This function is working fine in PHP 4.0.1 and up to 4.3.10 (the
highest of our
test configuration.)
Since PHP5 (different versions) it was not working anymore when you
call the function with $GLOBALS as
parameter. The logfile contained only one line ...
|-> GLOBALS = Array
After some hours i go it working by replacing the preg_replace()
function with
the ereg_replace() function.
The problem shows as follows:
After calling function preg_replace() the $GLOBALS array contails only
1 element
which is $GLOBALS. (i cheched it with count($GLOBALS);) after that the
check
is_array() is always returning "1" instead of true or false.
after replacing the ...
preg_replace("/\r*\n/", " ", $entry);
... with ...
ereg_replace("\n", " ", $entry);
ereg_replace("\r", " ", $entry);
... the function is working without problems. PHP must be configured
correctly
because this function preg_replace() is used very often in our program.
This
function is also workinf fine when called with any other array. Only
when
$GLOBALS is used to call this function it shows this behaviour.
We checked this behaviour with different PHP4.x (everything was
working) and some versions of PHP5 (on all the same problem - last
tested version 5.1.1). And also on different OS (Linux, MacOSX, WinXP,
Win2000).
Reproduce code:
---
$value){
$entry = $value;
$entry = preg_replace("/\r*\n/", " ", $entry);
$entry2 = "$level_space|-> $key = $entry\n";
$FILE = fopen("array.log", "a");
fwrite($FILE, $entry2);
fclose($FILE);
echo is_array($value);
if(is_array($value)){
if($key == "GLOBALS"){ continue; }
array_log($value, $level + 1);
}
}
}
?>
Expected result:
Logfile with PHP 5.1.1:
|-> GLOBALS = Array
Logfile with 4.x.x (as it should look like):
|-> HTTP_ENV_VARS = Array
|-> DBROOT = /dev/null
|-> BOOT_FILE = /boot/vmlinuz
|-> HOSTNAME = mail
|-> CONSOLE = /dev/console
|-> LD_LIBRARY_PATH = :/lib
.
.
.
|-> HTTP_POST_FILES = Array
|-> GLOBALS = Array
|-> GATEWAY_INTERFACE = CGI/1.1
|-> SERVER_PROTOCOL = HTTP/1.0
|-> REQUEST_METHOD = GET
|-> QUERY_STRING =
.
.
.
Actual result:
--
Replace ...
$entry = preg_replace("/\r*\n/", " ", $entry);
... With ...
$entry = ereg_replace("\r", "", $entry);
$entry = ereg_replace("\n", " ", $entry);
After changing it to ereg_replace() it is working with PHP4.0.1, 4.3.10
and 5.1.1
--
Edit this bug report at http://bugs.php.net/?id=35733&edit=1
#35733 [Opn->Bgs]: preg_replace() distroys $GLOBALS
ID: 35733
Updated by: [EMAIL PROTECTED]
Reported By: gerhard at tinned-software dot net
-Status: Open
+Status: Bogus
Bug Type: PCRE related
Operating System: WinXP/Linux
PHP Version: 5.1.1
New Comment:
If it worked in PHP 4 it's a bug there. Don't play around with GLOBALS
like that. It's expected behaviour to work unexpectedly.
Previous Comments:
[2005-12-19 16:21:56] gerhard at tinned-software dot net
with preg_replace i only remove newlines from a string which contains
the content of the variable! $value contains the content of the
variable and is copied to $entry ... only $entry is changed not the
$value which is used to check if it is an array and which is aslo used
to call the function recursive!
foreach($array as $key => $value){
$entry = $value;
how can this damage the $GLOBALS??? ... and if this is not a bug, way
it is working with PHP4.x???
[2005-12-19 15:12:47] [EMAIL PROTECTED]
$GLOBALS contains reference to itself.
In your code you're effectively converting all the elements to strings
with preg_replace(), so GLOBALS itself becomes string too.
Not a bug.
[2005-12-19 15:01:19] gerhard at tinned-software dot net
Description:
PHP 5 PCRE Bug!?
We have in our program a function to log all $GLOBALS variables. This
function
calls itself recursive to log all variables of a array and all its
sub-arrays.
This function is working fine in PHP 4.0.1 and up to 4.3.10 (the
highest of our
test configuration.)
Since PHP5 (different versions) it was not working anymore when you
call the function with $GLOBALS as
parameter. The logfile contained only one line ...
|-> GLOBALS = Array
After some hours i go it working by replacing the preg_replace()
function with
the ereg_replace() function.
The problem shows as follows:
After calling function preg_replace() the $GLOBALS array contails only
1 element
which is $GLOBALS. (i cheched it with count($GLOBALS);) after that the
check
is_array() is always returning "1" instead of true or false.
after replacing the ...
preg_replace("/\r*\n/", " ", $entry);
... with ...
ereg_replace("\n", " ", $entry);
ereg_replace("\r", " ", $entry);
... the function is working without problems. PHP must be configured
correctly
because this function preg_replace() is used very often in our program.
This
function is also workinf fine when called with any other array. Only
when
$GLOBALS is used to call this function it shows this behaviour.
We checked this behaviour with different PHP4.x (everything was
working) and some versions of PHP5 (on all the same problem - last
tested version 5.1.1). And also on different OS (Linux, MacOSX, WinXP,
Win2000).
Reproduce code:
---
$value){
$entry = $value;
$entry = preg_replace("/\r*\n/", " ", $entry);
$entry2 = "$level_space|-> $key = $entry\n";
$FILE = fopen("array.log", "a");
fwrite($FILE, $entry2);
fclose($FILE);
echo is_array($value);
if(is_array($value)){
if($key == "GLOBALS"){ continue; }
array_log($value, $level + 1);
}
}
}
?>
Expected result:
Logfile with PHP 5.1.1:
|-> GLOBALS = Array
Logfile with 4.x.x (as it should look like):
|-> HTTP_ENV_VARS = Array
|-> DBROOT = /dev/null
|-> BOOT_FILE = /boot/vmlinuz
|-> HOSTNAME = mail
|-> CONSOLE = /dev/console
|-> LD_LIBRARY_PATH = :/lib
.
.
.
|-> HTTP_POST_FILES = Array
|-> GLOBALS = Array
|-> GATEWAY_INTERFACE = CGI/1.1
|-> SERVER_PROTOCOL = HTTP/1.0
|-> REQUEST_METHOD = GET
|-> QUERY_STRING =
.
.
.
Actual result:
--
Replace ...
$entry = preg_replace("/\r*\n/", " ", $entry);
... With ...
$entry = ereg_replace("\r", "", $entry);
$entry = ereg_replace("\n", " ", $entry);
After changing it to ereg_replace() it is working with PHP4.0.1, 4.3.10
and 5.1.1
--
Edit this bug report at http://bugs.php.net/?id=35733&edit=1
#35734 [NEW]: RecursiveIteratorIterator constructor fails to recognize mode constants
From: dpantel at gmail dot com
Operating system: RHES (linux 2.4.21-37)
PHP version: 5.1.1
PHP Bug Type: SPL related
Bug description: RecursiveIteratorIterator constructor fails to recognize mode
constants
Description:
RecursiveIteratorIterator constructor fails to recognize mode constants.
The constructor works fine when passed only a RecursiveIterator object.
It also functions correctly if passed a RecursiveIterator object and an
integer (0,1,2, etc) as the second (mode) argument. However, if one
attempts to pass a documented constant keyword (RIT_SELF_FIRST or
SELF_FIRST), the constructor fails.
Note: different documentations show different constant definitions
(RIT_SELF_FIRST vs SELF_FIRST). I have tried both, and neither one works.
Reproduce code:
---
class Rit implements RecursiveIterator {...}
$test = new Rit();
//work fine
$rii = new RecursiveIteratorIterator($test);
$rii = new RecursiveIteratorIterator($test, 1);
//do not work
$rii = new RecursiveIteratorIterator($test, RIT_SELF_FIRST);
$rii = new RecursiveIteratorIterator($test, SELF_FIRST);
//even tried this, with no avail
$rii = new RecursiveIteratorIterator($test,
RecursiveIteratorIterator::RIT_SELF_FIRST);
$rii = new RecursiveIteratorIterator($test,
RecursiveIteratorIterator::SELF_FIRST);
Expected result:
A RecursiveIteratorIterator object
Actual result:
--
Notice: Use of undefined constant RIT_SELF_FIRST - assumed
'RIT_SELF_FIRST' in /www/rit.class.php on line 276
(or Notice: Use of undefined constant SELF_FIRST - assumed 'SELF_FIRST' in
/www/rit.class.php on line 276)
Fatal error: Uncaught exception 'InvalidArgumentException' with message
'An instance of RecursiveIterator or IteratorAggregate creating it is
required' in /www/rit.class.php:276 Stack trace: #0
/www/rit.class.php(276):
RecursiveIteratorIterator->__construct(Object(treeIterator),
'RIT_SELF_FIRST') ...
--
Edit bug report at http://bugs.php.net/?id=35734&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=35734&r=trysnapshot44
Try a CVS snapshot (PHP 5.1):
http://bugs.php.net/fix.php?id=35734&r=trysnapshot51
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=35734&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=35734&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=35734&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=35734&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=35734&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=35734&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=35734&r=support
Expected behavior:http://bugs.php.net/fix.php?id=35734&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=35734&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=35734&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=35734&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=35734&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=35734&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=35734&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=35734&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=35734&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=35734&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=35734&r=mysqlcfg
#35733 [Bgs->Opn]: preg_replace() distroys $GLOBALS
ID: 35733
User updated by: gerhard at tinned-software dot net
-Reported By: gerhard at tinned-mail dot net
+Reported By: gerhard at tinned-software dot net
-Status: Bogus
+Status: Open
Bug Type: PCRE related
-Operating System: WinXP
+Operating System: WinXP/Linux
PHP Version: 5.1.1
New Comment:
with preg_replace i only remove newlines from a string which contains
the content of the variable! $value contains the content of the
variable and is copied to $entry ... only $entry is changed not the
$value which is used to check if it is an array and which is aslo used
to call the function recursive!
foreach($array as $key => $value){
$entry = $value;
how can this damage the $GLOBALS??? ... and if this is not a bug, way
it is working with PHP4.x???
Previous Comments:
[2005-12-19 15:12:47] [EMAIL PROTECTED]
$GLOBALS contains reference to itself.
In your code you're effectively converting all the elements to strings
with preg_replace(), so GLOBALS itself becomes string too.
Not a bug.
[2005-12-19 15:01:19] gerhard at tinned-software dot net
Description:
PHP 5 PCRE Bug!?
We have in our program a function to log all $GLOBALS variables. This
function
calls itself recursive to log all variables of a array and all its
sub-arrays.
This function is working fine in PHP 4.0.1 and up to 4.3.10 (the
highest of our
test configuration.)
Since PHP5 (different versions) it was not working anymore when you
call the function with $GLOBALS as
parameter. The logfile contained only one line ...
|-> GLOBALS = Array
After some hours i go it working by replacing the preg_replace()
function with
the ereg_replace() function.
The problem shows as follows:
After calling function preg_replace() the $GLOBALS array contails only
1 element
which is $GLOBALS. (i cheched it with count($GLOBALS);) after that the
check
is_array() is always returning "1" instead of true or false.
after replacing the ...
preg_replace("/\r*\n/", " ", $entry);
... with ...
ereg_replace("\n", " ", $entry);
ereg_replace("\r", " ", $entry);
... the function is working without problems. PHP must be configured
correctly
because this function preg_replace() is used very often in our program.
This
function is also workinf fine when called with any other array. Only
when
$GLOBALS is used to call this function it shows this behaviour.
We checked this behaviour with different PHP4.x (everything was
working) and some versions of PHP5 (on all the same problem - last
tested version 5.1.1). And also on different OS (Linux, MacOSX, WinXP,
Win2000).
Reproduce code:
---
$value){
$entry = $value;
$entry = preg_replace("/\r*\n/", " ", $entry);
$entry2 = "$level_space|-> $key = $entry\n";
$FILE = fopen("array.log", "a");
fwrite($FILE, $entry2);
fclose($FILE);
echo is_array($value);
if(is_array($value)){
if($key == "GLOBALS"){ continue; }
array_log($value, $level + 1);
}
}
}
?>
Expected result:
Logfile with PHP 5.1.1:
|-> GLOBALS = Array
Logfile with 4.x.x (as it should look like):
|-> HTTP_ENV_VARS = Array
|-> DBROOT = /dev/null
|-> BOOT_FILE = /boot/vmlinuz
|-> HOSTNAME = mail
|-> CONSOLE = /dev/console
|-> LD_LIBRARY_PATH = :/lib
.
.
.
|-> HTTP_POST_FILES = Array
|-> GLOBALS = Array
|-> GATEWAY_INTERFACE = CGI/1.1
|-> SERVER_PROTOCOL = HTTP/1.0
|-> REQUEST_METHOD = GET
|-> QUERY_STRING =
.
.
.
Actual result:
--
Replace ...
$entry = preg_replace("/\r*\n/", " ", $entry);
... With ...
$entry = ereg_replace("\r", "", $entry);
$entry = ereg_replace("\n", " ", $entry);
After changing it to ereg_replace() it is working with PHP4.0.1, 4.3.10
and 5.1.1
--
Edit this bug report at http://bugs.php.net/?id=35733&edit=1
#35682 [Opn->Fbk]: Segmentation fault...
ID: 35682 Updated by: [EMAIL PROTECTED] Reported By: necat at digicol dot de -Status: Open +Status: Feedback Bug Type: OCI8 related Operating System: ia64-hp-hpux11.23 PHP Version: 5.1.1 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip And please check that you've set ORACLE_HOME env variable and it points to the right dir. Previous Comments: [2005-12-19 15:38:00] necat at digicol dot de GDB backtrace = Script started on Mon Dec 19 15:16:29 2005 $ /opt/langtools/bin/gdb php core HP gdb 5.2.03 for HP Itanium (32 or 64 bit) and target HP-UX 11.2x. Copyright 1986 - 2001 Free Software Foundation, Inc. Hewlett-Packard Wildebeest 5.2.03 (based on GDB) is covered by the GNU General Public License. Type "show copying" to see the conditions to change it and/or distribute copies. Type "show warranty" for warranty/support. .. Core was generated by `php'. Program terminated with signal 11, Segmentation fault. SEGV_MAPERR - Address not mapped to object warning: Load module /usr/local/lib/hpux32/libgdbm.so has been stripped. Debugging information is not available. warning: Load module /usr/local/lib/hpux32/libz.so has been stripped. Debugging information is not available. warning: Load module /dc5/home/appdc5/oracle/ORAHOME/lib32/libclntsh.so.10.1 has been stripped. Debugging information is not available. warning: Load module /usr/local/lib/hpux32/libxml2.so has been stripped. Debugging information is not available. warning: Load module /usr/local/lib/hpux32/libpthread.so has been stripped. Debugging information is not available. warning: Load module /usr/local/lib/hpux32/libiconv.so has been stripped. Debugging information is not available. warning: Load module /dc5/home/appdc5/oracle/ORAHOME/lib32/libnnz10.so has been stripped. Debugging information is not available. #0 0x6000c1f25910:1 in pth_mutex_acquire+0x61 () from /usr/local/lib/hpux32/libpthread.so (gdb) bt #0 0x6000c1f25910:1 in pth_mutex_acquire+0x61 () from /usr/local/lib/hpux32/libpthread.so #1 0x6000c1f14a60:0 in pthread_mutex_lock+0xf0 () from /usr/local/lib/hpux32/libpthread.so #2 0x6000c6d91cc0:0 in sltsima+0x40 () from /dc5/home/appdc5/oracle/ORAHOME/lib32/libclntsh.so.10.1 #3 0x6000c672b9a0:0 in kpummpin+0x60 () from /dc5/home/appdc5/oracle/ORAHOME/lib32/libclntsh.so.10.1 #4 0x6000c56d4620:0 in kpupin+0xa0 () from /dc5/home/appdc5/oracle/ORAHOME/lib32/libclntsh.so.10.1 #5 0x6000c580d4e0:0 in OCIInitialize+0x40 () from /dc5/home/appdc5/oracle/ORAHOME/lib32/libclntsh.so.10.1 #6 0x43954d0:0 in zm_startup_oci (type=1, module_number=13) at /dc5/home/appdc5/Sourcen/php-5.1.1/ext/oci8/oci8.c:638 #7 0x4721360:0 in zend_startup_module_ex () at /dc5/home/appdc5/Sourcen/php-5.1.1/Zend/zend_API.c:1341 #8 0x472a890:0 in zend_hash_apply (apply_func=0x7a95eeb8) at /dc5/home/appdc5/Sourcen/php-5.1.1/Zend/zend_hash.c:664 #9 0x4719690:0 in zend_startup_modules () at /dc5/home/appdc5/Sourcen/php-5.1.1/Zend/zend_API.c:1388 #10 0x46774e0:0 in php_module_startup () at /dc5/home/appdc5/Sourcen/php-5.1.1/main/main.c:1533 #11 0x48cd7f0:0 in main () at /dc5/home/appdc5/Sourcen/php-5.1.1/sapi/cli/php_cli.c:655 (gdb) quit $ exit script done on Mon Dec 19 15:17:08 2005 [2005-12-15 15:20:25] [EMAIL PROTECTED] 1) "checking checking if we're at 64-bit platform... no" This looks kinda suspicious, Try this: rm config.cache ./configure ... make 2) Please show the GDB backtrace. [2005-12-15 15:15:11] necat at digicol dot de Description: Hi, oracle client version 10.1 is installed. I configured apache version 1.3.34 and then configured php version 5.1.1 with oci8 and some other options that we need. php configure gives the following messages: checking for Oracle (OCI8) support using ORACLE_HOME installation... yes checking Oracle Install Directory... /dc5/home/appdc5/oracle/ORAHOME checking size of long int... (cached) 4 checking checking if we're at 64-bit platform... no checking OCI8 libraries dir... lib32 checking Oracle version... configure: error: Oracle-OCI8 needed libraries not found Reproduce code: --- when I change SHLIB_SUFFIX_NAME=sl to SHLIB_SUFFIX_NAME=so in configure file, configure has no problem. Oracle Client installation has on this machine no sl libraries. case $host_alias in *hpux*) SHLIB_SUFFIX_NAME=sl ;; and the compiling of code is successfully. But when I call php binary like php -v or php -i gives segmentation fault. Actual result: -- [EMAIL PROTECTED]:/dc5/home/appdc5/Source
#35682 [Fbk->Opn]: Segmentation fault...
ID: 35682 User updated by: necat at digicol dot de Reported By: necat at digicol dot de -Status: Feedback +Status: Open Bug Type: OCI8 related Operating System: ia64-hp-hpux11.23 PHP Version: 5.1.1 New Comment: GDB backtrace = Script started on Mon Dec 19 15:16:29 2005 $ /opt/langtools/bin/gdb php core HP gdb 5.2.03 for HP Itanium (32 or 64 bit) and target HP-UX 11.2x. Copyright 1986 - 2001 Free Software Foundation, Inc. Hewlett-Packard Wildebeest 5.2.03 (based on GDB) is covered by the GNU General Public License. Type "show copying" to see the conditions to change it and/or distribute copies. Type "show warranty" for warranty/support. .. Core was generated by `php'. Program terminated with signal 11, Segmentation fault. SEGV_MAPERR - Address not mapped to object warning: Load module /usr/local/lib/hpux32/libgdbm.so has been stripped. Debugging information is not available. warning: Load module /usr/local/lib/hpux32/libz.so has been stripped. Debugging information is not available. warning: Load module /dc5/home/appdc5/oracle/ORAHOME/lib32/libclntsh.so.10.1 has been stripped. Debugging information is not available. warning: Load module /usr/local/lib/hpux32/libxml2.so has been stripped. Debugging information is not available. warning: Load module /usr/local/lib/hpux32/libpthread.so has been stripped. Debugging information is not available. warning: Load module /usr/local/lib/hpux32/libiconv.so has been stripped. Debugging information is not available. warning: Load module /dc5/home/appdc5/oracle/ORAHOME/lib32/libnnz10.so has been stripped. Debugging information is not available. #0 0x6000c1f25910:1 in pth_mutex_acquire+0x61 () from /usr/local/lib/hpux32/libpthread.so (gdb) bt #0 0x6000c1f25910:1 in pth_mutex_acquire+0x61 () from /usr/local/lib/hpux32/libpthread.so #1 0x6000c1f14a60:0 in pthread_mutex_lock+0xf0 () from /usr/local/lib/hpux32/libpthread.so #2 0x6000c6d91cc0:0 in sltsima+0x40 () from /dc5/home/appdc5/oracle/ORAHOME/lib32/libclntsh.so.10.1 #3 0x6000c672b9a0:0 in kpummpin+0x60 () from /dc5/home/appdc5/oracle/ORAHOME/lib32/libclntsh.so.10.1 #4 0x6000c56d4620:0 in kpupin+0xa0 () from /dc5/home/appdc5/oracle/ORAHOME/lib32/libclntsh.so.10.1 #5 0x6000c580d4e0:0 in OCIInitialize+0x40 () from /dc5/home/appdc5/oracle/ORAHOME/lib32/libclntsh.so.10.1 #6 0x43954d0:0 in zm_startup_oci (type=1, module_number=13) at /dc5/home/appdc5/Sourcen/php-5.1.1/ext/oci8/oci8.c:638 #7 0x4721360:0 in zend_startup_module_ex () at /dc5/home/appdc5/Sourcen/php-5.1.1/Zend/zend_API.c:1341 #8 0x472a890:0 in zend_hash_apply (apply_func=0x7a95eeb8) at /dc5/home/appdc5/Sourcen/php-5.1.1/Zend/zend_hash.c:664 #9 0x4719690:0 in zend_startup_modules () at /dc5/home/appdc5/Sourcen/php-5.1.1/Zend/zend_API.c:1388 #10 0x46774e0:0 in php_module_startup () at /dc5/home/appdc5/Sourcen/php-5.1.1/main/main.c:1533 #11 0x48cd7f0:0 in main () at /dc5/home/appdc5/Sourcen/php-5.1.1/sapi/cli/php_cli.c:655 (gdb) quit $ exit script done on Mon Dec 19 15:17:08 2005 Previous Comments: [2005-12-15 15:20:25] [EMAIL PROTECTED] 1) "checking checking if we're at 64-bit platform... no" This looks kinda suspicious, Try this: rm config.cache ./configure ... make 2) Please show the GDB backtrace. [2005-12-15 15:15:11] necat at digicol dot de Description: Hi, oracle client version 10.1 is installed. I configured apache version 1.3.34 and then configured php version 5.1.1 with oci8 and some other options that we need. php configure gives the following messages: checking for Oracle (OCI8) support using ORACLE_HOME installation... yes checking Oracle Install Directory... /dc5/home/appdc5/oracle/ORAHOME checking size of long int... (cached) 4 checking checking if we're at 64-bit platform... no checking OCI8 libraries dir... lib32 checking Oracle version... configure: error: Oracle-OCI8 needed libraries not found Reproduce code: --- when I change SHLIB_SUFFIX_NAME=sl to SHLIB_SUFFIX_NAME=so in configure file, configure has no problem. Oracle Client installation has on this machine no sl libraries. case $host_alias in *hpux*) SHLIB_SUFFIX_NAME=sl ;; and the compiling of code is successfully. But when I call php binary like php -v or php -i gives segmentation fault. Actual result: -- [EMAIL PROTECTED]:/dc5/home/appdc5/Sourcen/php-5.1.1/sapi/cli>./php -v Segmentation fault (core dumped) [EMAIL PROTECTED]:/dc5/home/appdc5/Sourcen/php-5.1.1/sapi/cli>./php -i Segmentation fault (core dumped) Regards, N.Kutlar -- Edit this bug report at http://bugs.php.net/?id=35682&edit=1
#35447 [Asn->Csd]: xml_parse_into_struct() chokes on the UTF-8 BOM
ID: 35447 Updated by: [EMAIL PROTECTED] Reported By: saramaca at libertysurf dot fr -Status: Assigned +Status: Closed Bug Type: XML related Operating System: * PHP Version: 5CVS-2005-12-19 (cvs) Assigned To: rrichards New Comment: This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. as for default values you have to create namespace parser for those to work. Previous Comments: [2005-12-19 08:57:09] [EMAIL PROTECTED] Rob, what's the status with this? [2005-11-28 20:28:32] [EMAIL PROTECTED] As far as the default attribute values - have to check on expat behavior. The other issue is fixed with libxml2 2.6.18. I have a patch (http://www.ctindustries.net/patches/xml.compat.diff.txt) that looks like it should work around the issue with older libxml2 libs, but need more testing with different encoding/BOM schemes to make sure it doesnt break anything as were playing with the libxml encoding handling here. [2005-11-28 18:03:18] [EMAIL PROTECTED] expat vs libxml2 incompatibility? [2005-11-28 14:55:33] saramaca at libertysurf dot fr Description: In PHP4 xml_parse_into_struct() can parse an UTF-8-encoded XML file with or without a UTF-8 BOM (\xEF\xBB\xBF). In PHP 5, this is no longer the case and it raises an error saying the string doesn't contain any XML data (Empty document). Additionally PHP 5's xml_parse_into_struct() does *NOT* place default attribute values into the struct (e.g. despite the DTD provided, $content[1]['attributes']['type'] isn't set to "literal" in actual result section below ; please compare it to expected result.) This used to work under PHP 4.1.x and above (but the parser is based on expat AFAIK.) PS: I guess "manually" stripping this magic number -- if embedded -- before calling the function would yield the expected result. However I found an acceptable work-around that seems to work equally well across versions 4 and 5 of PHP : Rather than: Reproduce code: --- http://www.diptyque.net/bugs/utf8_bom.php ; running PHP 4 --> outputs expected result http://www.diptyque.net/bugs/utf8_bom.phps ; source code Expected result: w/ autodetect --> Array ( [0] => Array ( [tag] => bundle [type] => open [level] => 1 [value] => ) [1] => Array ( [tag] => resource [type] => complete [level] => 2 [attributes] => Array ( [key] => rSeeYou [type] => literal ) [value] => A bient&244;t ) [2] => Array ( [tag] => bundle [value] => [type] => cdata [level] => 1 ) [3] => Array ( [tag] => bundle [type] => close [level] => 1 ) ) w/o autodetect --> Array ( [0] => Array ( [tag] => bundle [type] => open [level] => 1 [value] => ) [1] => Array ( [tag] => resource [type] => complete [level] => 2 [attributes] => Array ( [key] => rSeeYou [type] => literal ) [value] => A bient&244;t ) [2] => Array ( [tag] => bundle [value] => [type] => cdata [level] => 1 ) [3] => Array ( [tag] => bundle [type] => close [level] => 1 ) ) Actual result: -- w/ autodetect --> Array ( [0] => Array ( [tag] => bundle [type] => open [level] => 1 [value] => ) [1] => Array ( [tag] => resource [type] => complete [level] => 2 [attributes] => Array ( [key] => rSeeYou ) [value] => A bient&244;t ) [2] => Array ( [tag] => bundle [value] => [type] => cdata [level] => 1 ) [3] => Array ( [tag] => bundle [type] => close [level] => 1 ) ) w/o autodetect --> Empty document ---
#35733 [Opn->Bgs]: preg_replace() distroys $GLOBALS
ID: 35733
Updated by: [EMAIL PROTECTED]
Reported By: gerhard at tinned-mail dot net
-Status: Open
+Status: Bogus
Bug Type: PCRE related
Operating System: WinXP
PHP Version: 5.1.1
New Comment:
$GLOBALS contains reference to itself.
In your code you're effectively converting all the elements to strings
with preg_replace(), so GLOBALS itself becomes string too.
Not a bug.
Previous Comments:
[2005-12-19 15:01:19] gerhard at tinned-mail dot net
Description:
PHP 5 PCRE Bug!?
We have in our program a function to log all $GLOBALS variables. This
function
calls itself recursive to log all variables of a array and all its
sub-arrays.
This function is working fine in PHP 4.0.1 and up to 4.3.10 (the
highest of our
test configuration.)
Since PHP5 (different versions) it was not working anymore when you
call the function with $GLOBALS as
parameter. The logfile contained only one line ...
|-> GLOBALS = Array
After some hours i go it working by replacing the preg_replace()
function with
the ereg_replace() function.
The problem shows as follows:
After calling function preg_replace() the $GLOBALS array contails only
1 element
which is $GLOBALS. (i cheched it with count($GLOBALS);) after that the
check
is_array() is always returning "1" instead of true or false.
after replacing the ...
preg_replace("/\r*\n/", " ", $entry);
... with ...
ereg_replace("\n", " ", $entry);
ereg_replace("\r", " ", $entry);
... the function is working without problems. PHP must be configured
correctly
because this function preg_replace() is used very often in our program.
This
function is also workinf fine when called with any other array. Only
when
$GLOBALS is used to call this function it shows this behaviour.
We checked this behaviour with different PHP4.x (everything was
working) and some versions of PHP5 (on all the same problem - last
tested version 5.1.1). And also on different OS (Linux, MacOSX, WinXP,
Win2000).
Reproduce code:
---
$value){
$entry = $value;
$entry = preg_replace("/\r*\n/", " ", $entry);
$entry2 = "$level_space|-> $key = $entry\n";
$FILE = fopen("array.log", "a");
fwrite($FILE, $entry2);
fclose($FILE);
echo is_array($value);
if(is_array($value)){
if($key == "GLOBALS"){ continue; }
array_log($value, $level + 1);
}
}
}
?>
Expected result:
Logfile with PHP 5.1.1:
|-> GLOBALS = Array
Logfile with 4.x.x (as it should look like):
|-> HTTP_ENV_VARS = Array
|-> DBROOT = /dev/null
|-> BOOT_FILE = /boot/vmlinuz
|-> HOSTNAME = mail
|-> CONSOLE = /dev/console
|-> LD_LIBRARY_PATH = :/lib
.
.
.
|-> HTTP_POST_FILES = Array
|-> GLOBALS = Array
|-> GATEWAY_INTERFACE = CGI/1.1
|-> SERVER_PROTOCOL = HTTP/1.0
|-> REQUEST_METHOD = GET
|-> QUERY_STRING =
.
.
.
Actual result:
--
Replace ...
$entry = preg_replace("/\r*\n/", " ", $entry);
... With ...
$entry = ereg_replace("\r", "", $entry);
$entry = ereg_replace("\n", " ", $entry);
After changing it to ereg_replace() it is working with PHP4.0.1, 4.3.10
and 5.1.1
--
Edit this bug report at http://bugs.php.net/?id=35733&edit=1
#35733 [NEW]: preg_replace() distroys $GLOBALS
From: gerhard at tinned-mail dot net
Operating system: WinXP
PHP version: 5.1.1
PHP Bug Type: PCRE related
Bug description: preg_replace() distroys $GLOBALS
Description:
PHP 5 PCRE Bug!?
We have in our program a function to log all $GLOBALS variables. This
function
calls itself recursive to log all variables of a array and all its
sub-arrays.
This function is working fine in PHP 4.0.1 and up to 4.3.10 (the highest
of our
test configuration.)
Since PHP5 (different versions) it was not working anymore when you call
the function with $GLOBALS as
parameter. The logfile contained only one line ...
|-> GLOBALS = Array
After some hours i go it working by replacing the preg_replace() function
with
the ereg_replace() function.
The problem shows as follows:
After calling function preg_replace() the $GLOBALS array contails only 1
element
which is $GLOBALS. (i cheched it with count($GLOBALS);) after that the
check
is_array() is always returning "1" instead of true or false.
after replacing the ...
preg_replace("/\r*\n/", " ", $entry);
... with ...
ereg_replace("\n", " ", $entry);
ereg_replace("\r", " ", $entry);
... the function is working without problems. PHP must be configured
correctly
because this function preg_replace() is used very often in our program.
This
function is also workinf fine when called with any other array. Only when
$GLOBALS is used to call this function it shows this behaviour.
We checked this behaviour with different PHP4.x (everything was working)
and some versions of PHP5 (on all the same problem - last tested version
5.1.1). And also on different OS (Linux, MacOSX, WinXP, Win2000).
Reproduce code:
---
$value){
$entry = $value;
$entry = preg_replace("/\r*\n/", " ", $entry);
$entry2 = "$level_space|-> $key = $entry\n";
$FILE = fopen("array.log", "a");
fwrite($FILE, $entry2);
fclose($FILE);
echo is_array($value);
if(is_array($value)){
if($key == "GLOBALS"){ continue; }
array_log($value, $level + 1);
}
}
}
?>
Expected result:
Logfile with PHP 5.1.1:
|-> GLOBALS = Array
Logfile with 4.x.x (as it should look like):
|-> HTTP_ENV_VARS = Array
|-> DBROOT = /dev/null
|-> BOOT_FILE = /boot/vmlinuz
|-> HOSTNAME = mail
|-> CONSOLE = /dev/console
|-> LD_LIBRARY_PATH = :/lib
.
.
.
|-> HTTP_POST_FILES = Array
|-> GLOBALS = Array
|-> GATEWAY_INTERFACE = CGI/1.1
|-> SERVER_PROTOCOL = HTTP/1.0
|-> REQUEST_METHOD = GET
|-> QUERY_STRING =
.
.
.
Actual result:
--
Replace ...
$entry = preg_replace("/\r*\n/", " ", $entry);
... With ...
$entry = ereg_replace("\r", "", $entry);
$entry = ereg_replace("\n", " ", $entry);
After changing it to ereg_replace() it is working with PHP4.0.1, 4.3.10
and 5.1.1
--
Edit bug report at http://bugs.php.net/?id=35733&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=35733&r=trysnapshot44
Try a CVS snapshot (PHP 5.1):
http://bugs.php.net/fix.php?id=35733&r=trysnapshot51
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=35733&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=35733&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=35733&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=35733&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=35733&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=35733&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=35733&r=support
Expected behavior:http://bugs.php.net/fix.php?id=35733&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=35733&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=35733&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=35733&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=35733&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=35733&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=35733&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=35733&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=35733&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=35733&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=35733&r=mysqlcfg
#35728 [Opn->Bgs]: constructors with a return by reference cause a notice to be thrown
ID: 35728 Updated by: [EMAIL PROTECTED] Reported By: t dot isler at bbn dot de -Status: Open +Status: Bogus Bug Type:Scripting Engine problem PHP Version: 5.1.1 New Comment: >Even if I remove the assignments by reference it does not > change the problem. Yes it does. >Next to fact that I do not see the sense of your code example That's exactly what I wanted to demonstrate. There is no point in returning by reference from constructor, since it doesn't return anything at all. Previous Comments: [2005-12-19 14:29:45] t dot isler at bbn dot de Even if I remove the assignments by reference it does not change the problem. Next to fact that I do not see the sense of your code example unless you wish to imply that constructors in PHP do not differ from regular functions. As far as OOP is concerned a constructor has an implicit return ($this) and languages such as C++ or Java will throw an error, if a constructor includes an explicit return. [2005-12-19 00:32:22] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php That's exactly what you get with this: And this is expected behaviour (because your code is obviously wrong). Also, if you set error_reporting to E_ALL | E_STRICT, you'll see even more error messages telling you about your code. [2005-12-19 00:18:50] t dot isler at bbn dot de Description: I don't know wether you want to consider the following a bug, but as far as my understanding of oop is concerned, the behavior of php 4.4 and 5.1 is "unusual" when comes to constructors with a return by reference. Reproduce code: --- Expected result: The first constructor should pass without a problem, the second should throw an error. Actual result: -- The first constructor throws a notice, the second passes without any problem. -- Edit this bug report at http://bugs.php.net/?id=35728&edit=1
#35728 [Bgs->Opn]: constructors with a return by reference cause a notice to be thrown
ID: 35728 User updated by: t dot isler at bbn dot de Reported By: t dot isler at bbn dot de -Status: Bogus +Status: Open Bug Type:Scripting Engine problem PHP Version: 5.1.1 New Comment: Even if I remove the assignments by reference it does not change the problem. Next to fact that I do not see the sense of your code example unless you wish to imply that constructors in PHP do not differ from regular functions. As far as OOP is concerned a constructor has an implicit return ($this) and languages such as C++ or Java will throw an error, if a constructor includes an explicit return. Previous Comments: [2005-12-19 00:32:22] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php That's exactly what you get with this: And this is expected behaviour (because your code is obviously wrong). Also, if you set error_reporting to E_ALL | E_STRICT, you'll see even more error messages telling you about your code. [2005-12-19 00:18:50] t dot isler at bbn dot de Description: I don't know wether you want to consider the following a bug, but as far as my understanding of oop is concerned, the behavior of php 4.4 and 5.1 is "unusual" when comes to constructors with a return by reference. Reproduce code: --- Expected result: The first constructor should pass without a problem, the second should throw an error. Actual result: -- The first constructor throws a notice, the second passes without any problem. -- Edit this bug report at http://bugs.php.net/?id=35728&edit=1
#35732 [Opn->Fbk]: Access violation on file open
ID: 35732 Updated by: [EMAIL PROTECTED] Reported By: rene at lico dot nl -Status: Open +Status: Feedback Bug Type: IIS related Operating System: Windows 2003 PHP Version: 5.1.1 New Comment: Yes. It's worth trying the latest version before starting to debug something. Previous Comments: [2005-12-19 13:44:53] rene at lico dot nl Is this the only way? I would rather use a debug method since the server is heavily used... [2005-12-19 13:11:00] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip [2005-12-19 13:04:33] rene at lico dot nl Description: Using PHP as ISAPI module results in getting "PHP has encountered an Access Violation at ...". The cause of this access violation is quite unknown to me and I have no idea how to debug this error. What I have found is that it _could_ happen on a file_get_contents or a fopen using the http wrapper. But again: i'm not sure. First of all: please help me in tracing down this problem. Reproduce code: --- http://localhost";); ?> Expected result: not the actual result :) Actual result: -- PHP has encountered an Access Violation at 010E2ED6 -- Edit this bug report at http://bugs.php.net/?id=35732&edit=1
#35731 [Fbk->Csd]: global _super global_
ID: 35731 User updated by: khad at landak dot com Reported By: khad at landak dot com -Status: Feedback +Status: Closed Bug Type: Session related Operating System: Linux 2.6 PHP Version: 5.1.1 New Comment: work using latest snapshot Previous Comments: [2005-12-19 10:15:08] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip Can't reproduce. [2005-12-19 10:08:28] khad at landak dot com Description: using global on super global causing segfault or memory corruption. I have large codes which written in nasty way ;) see Reproduce code it works under php 4 and pre 5.1 please helpp Reproduce code: --- http://bugs.php.net/?id=35731&edit=1
#35732 [Fbk->Opn]: Access violation on file open
ID: 35732 User updated by: rene at lico dot nl Reported By: rene at lico dot nl -Status: Feedback +Status: Open Bug Type: IIS related Operating System: Windows 2003 PHP Version: 5.1.1 New Comment: Is this the only way? I would rather use a debug method since the server is heavily used... Previous Comments: [2005-12-19 13:11:00] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip [2005-12-19 13:04:33] rene at lico dot nl Description: Using PHP as ISAPI module results in getting "PHP has encountered an Access Violation at ...". The cause of this access violation is quite unknown to me and I have no idea how to debug this error. What I have found is that it _could_ happen on a file_get_contents or a fopen using the http wrapper. But again: i'm not sure. First of all: please help me in tracing down this problem. Reproduce code: --- http://localhost";); ?> Expected result: not the actual result :) Actual result: -- PHP has encountered an Access Violation at 010E2ED6 -- Edit this bug report at http://bugs.php.net/?id=35732&edit=1
#35388 [Com]: crash on new object when passed incorrect access details
ID: 35388 Comment by: jhala at uoregon dot edu Reported By: [EMAIL PROTECTED] Status: No Feedback Bug Type: MySQLi related Operating System: Windows XP Home SP2 PHP Version: 5.1.0 Assigned To: georg New Comment: update on that. i made my instance of this problem go away and php/phpmyadmin worked fine by simply making sure that i copied libmysql.dll from the php main directory (where the phpinstall program put it automagically) to the extensions directory (which I had added to windows PATH). restarted apache, problem gone. hope this helps. Previous Comments: [2005-12-19 12:44:10] jhala at uoregon dot edu I had the same problem on winxp with apache 2.05, php 5.1.1 and mysql 5.1. I'd have to agree that it's likely a client problem - in this case, the client is phpmyadmin 2.7 - except that I had set up the exact same configuration on windows server 2003 (actually, i had brought everything over to the winxp machine, except set it up as a localhost webserver instead of an actual connected webserver), and i had no such problem on that. so i wonder, is it something funky with it being a localhost setup, or is there something server 2003 has that xp doesn't? [2005-12-08 01:00:04] 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". [2005-11-30 14:09:11] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip [2005-11-28 23:18:31] [EMAIL PROTECTED] Looks like there is a binary incompatibility in protocol when connecting from 4.1 client to 5.0.16. I was able to reproduce the problem under linux too. As a possible workaround you should compile PHP against 5.0.16 client lib. [2005-11-28 17:19:22] [EMAIL PROTECTED] I've downloaded the latest snapshot (problem still exists) and the win32 debug pack with the .pdb files. I've had a look on the PHP mailing lists and Google but can't find any help for actually using the debug pack. Can you point me in the right direction? 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/35388 -- Edit this bug report at http://bugs.php.net/?id=35388&edit=1
#35732 [Opn->Fbk]: Access violation on file open
ID: 35732 Updated by: [EMAIL PROTECTED] Reported By: rene at lico dot nl -Status: Open +Status: Feedback Bug Type: IIS related Operating System: Windows 2003 PHP Version: 5.1.1 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip Previous Comments: [2005-12-19 13:04:33] rene at lico dot nl Description: Using PHP as ISAPI module results in getting "PHP has encountered an Access Violation at ...". The cause of this access violation is quite unknown to me and I have no idea how to debug this error. What I have found is that it _could_ happen on a file_get_contents or a fopen using the http wrapper. But again: i'm not sure. First of all: please help me in tracing down this problem. Reproduce code: --- http://localhost";); ?> Expected result: not the actual result :) Actual result: -- PHP has encountered an Access Violation at 010E2ED6 -- Edit this bug report at http://bugs.php.net/?id=35732&edit=1
#35732 [NEW]: Access violation on file open
From: rene at lico dot nl Operating system: Windows 2003 PHP version: 5.1.1 PHP Bug Type: IIS related Bug description: Access violation on file open Description: Using PHP as ISAPI module results in getting "PHP has encountered an Access Violation at ...". The cause of this access violation is quite unknown to me and I have no idea how to debug this error. What I have found is that it _could_ happen on a file_get_contents or a fopen using the http wrapper. But again: i'm not sure. First of all: please help me in tracing down this problem. Reproduce code: --- http://localhost";); ?> Expected result: not the actual result :) Actual result: -- PHP has encountered an Access Violation at 010E2ED6 -- Edit bug report at http://bugs.php.net/?id=35732&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=35732&r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=35732&r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=35732&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=35732&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=35732&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=35732&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=35732&r=needscript Try newer version:http://bugs.php.net/fix.php?id=35732&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=35732&r=support Expected behavior:http://bugs.php.net/fix.php?id=35732&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=35732&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=35732&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=35732&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=35732&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=35732&r=dst IIS Stability:http://bugs.php.net/fix.php?id=35732&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=35732&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=35732&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=35732&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=35732&r=mysqlcfg
#35388 [Com]: crash on new object when passed incorrect access details
ID: 35388 Comment by: jhala at uoregon dot edu Reported By: [EMAIL PROTECTED] Status: No Feedback Bug Type: MySQLi related Operating System: Windows XP Home SP2 PHP Version: 5.1.0 Assigned To: georg New Comment: I had the same problem on winxp with apache 2.05, php 5.1.1 and mysql 5.1. I'd have to agree that it's likely a client problem - in this case, the client is phpmyadmin 2.7 - except that I had set up the exact same configuration on windows server 2003 (actually, i had brought everything over to the winxp machine, except set it up as a localhost webserver instead of an actual connected webserver), and i had no such problem on that. so i wonder, is it something funky with it being a localhost setup, or is there something server 2003 has that xp doesn't? Previous Comments: [2005-12-08 01:00:04] 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". [2005-11-30 14:09:11] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip [2005-11-28 23:18:31] [EMAIL PROTECTED] Looks like there is a binary incompatibility in protocol when connecting from 4.1 client to 5.0.16. I was able to reproduce the problem under linux too. As a possible workaround you should compile PHP against 5.0.16 client lib. [2005-11-28 17:19:22] [EMAIL PROTECTED] I've downloaded the latest snapshot (problem still exists) and the win32 debug pack with the .pdb files. I've had a look on the PHP mailing lists and Google but can't find any help for actually using the debug pack. Can you point me in the right direction? [2005-11-28 10:03:21] [EMAIL PROTECTED] If you'd install the latest CVS snapshot and the debug symbols, you'd propably get a bit better backtrace: http://snaps.php.net/ 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/35388 -- Edit this bug report at http://bugs.php.net/?id=35388&edit=1
#29840 [NoF->Opn]: is_executable does not honor the safe_mode_exec_dir setting
ID: 29840 Updated by: [EMAIL PROTECTED] Reported By: markus at cultcom dot de -Status: No Feedback +Status: Open Bug Type: Filesystem function related Operating System: * PHP Version: 5CVS, 4CVS (2005-01-04) Assigned To: tony2001 Previous Comments: [2005-12-05 11:17:08] [EMAIL PROTECTED] Any news on this? Would appreciate this patch in PHP4 and PHP5 [2005-08-22 13:41:44] fogbank at fogbank dot org This bug is present in version 4.4.0, too. Please, fix it, since right now it breaks every package in PEAR that relies on System::which(). [2005-08-20 01:00:03] 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". [2005-08-12 01:00:33] [EMAIL PROTECTED] Please try this patch: http://tony2001.phpclub.net/dev/tmp/bugs_29840_31618.diff (with the latest snapshot/CVS). [2004-12-12 11:36:05] [EMAIL PROTECTED] Jani, I sent a patch for this problem to Wez long ago. The problem is that is_executable() indeed doesn't respect safe_mode_exec_dir as it should, so I'm assigning this to Wez. 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/29840 -- Edit this bug report at http://bugs.php.net/?id=29840&edit=1
#35730 [Opn->Asn]: mssql didn't use the right character encoding in freetds.conf
ID: 35730 Updated by: [EMAIL PROTECTED] Reported By: liang at saga-city dot com -Status: Open +Status: Assigned Bug Type: MSSQL related Operating System: FreeBSD PHP Version: 5.1.1 -Assigned To: +Assigned To: fmk Previous Comments: [2005-12-19 05:48:08] liang at saga-city dot com we have been testing the mssql extension both in PHP4 and PHP5.1.1, " with the same freetds.conf " tds version = 8.0 client charset = BIG-5 In php4, it works fine, but not in php5.1.1 ( our old system uses php5.0.3 also work fine in the "same" freetds.conf ) [2005-12-19 03:27:06] [EMAIL PROTECTED] All encoding is handled by freetds in both PHP4 and PHP5. Execpt for internal PHP stuff the mssql extension is the same for PHP4 and PHP5. You need to change the encoding in freetds.conf. [2005-12-19 02:29:00] liang at saga-city dot com Description: php5 mssql didn't use character encoding specify in freetds.conf ( alwasy use ISO-8559-1 , seen in freetds.log ) switch to php4 , everythings works fine -- Edit this bug report at http://bugs.php.net/?id=35730&edit=1
#35731 [Opn->Fbk]: global _super global_
ID: 35731 Updated by: [EMAIL PROTECTED] Reported By: khad at landak dot com -Status: Open +Status: Feedback -Bug Type: Scripting Engine problem +Bug Type: Session related Operating System: Linux 2.6 PHP Version: 5.1.1 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip Can't reproduce. Previous Comments: [2005-12-19 10:08:28] khad at landak dot com Description: using global on super global causing segfault or memory corruption. I have large codes which written in nasty way ;) see Reproduce code it works under php 4 and pre 5.1 please helpp Reproduce code: --- http://bugs.php.net/?id=35731&edit=1
#35731 [NEW]: global _super global_
From: khad at landak dot com Operating system: Linux 2.6 PHP version: 5.1.1 PHP Bug Type: Scripting Engine problem Bug description: global _super global_ Description: using global on super global causing segfault or memory corruption. I have large codes which written in nasty way ;) see Reproduce code it works under php 4 and pre 5.1 please helpp Reproduce code: --- http://bugs.php.net/?id=35731&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=35731&r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=35731&r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=35731&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=35731&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=35731&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=35731&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=35731&r=needscript Try newer version:http://bugs.php.net/fix.php?id=35731&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=35731&r=support Expected behavior:http://bugs.php.net/fix.php?id=35731&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=35731&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=35731&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=35731&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=35731&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=35731&r=dst IIS Stability:http://bugs.php.net/fix.php?id=35731&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=35731&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=35731&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=35731&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=35731&r=mysqlcfg
#35730 [Bgs->Opn]: mssql didn't use the right character encoding in freetds.conf
ID: 35730 User updated by: liang at saga-city dot com Reported By: liang at saga-city dot com -Status: Bogus +Status: Open Bug Type: MSSQL related Operating System: FreeBSD PHP Version: 5.1.1 New Comment: well, thanks two gentlemen's response. the same compile configuration and the same freetds.conf PHP4 and PHP5.0.3 works fine, but not PHP5.1.1?! It's the BOGUS for not knowing how to use Freetds? Anyway, we can survive with the PHP5.0.3 and wait for smarty to find out. Cheers, Previous Comments: [2005-12-19 08:46:17] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. [2005-12-19 05:48:08] liang at saga-city dot com we have been testing the mssql extension both in PHP4 and PHP5.1.1, " with the same freetds.conf " tds version = 8.0 client charset = BIG-5 In php4, it works fine, but not in php5.1.1 ( our old system uses php5.0.3 also work fine in the "same" freetds.conf ) [2005-12-19 03:27:06] [EMAIL PROTECTED] All encoding is handled by freetds in both PHP4 and PHP5. Execpt for internal PHP stuff the mssql extension is the same for PHP4 and PHP5. You need to change the encoding in freetds.conf. [2005-12-19 02:29:00] liang at saga-city dot com Description: php5 mssql didn't use character encoding specify in freetds.conf ( alwasy use ISO-8559-1 , seen in freetds.log ) switch to php4 , everythings works fine -- Edit this bug report at http://bugs.php.net/?id=35730&edit=1
#32503 [Opn->Fbk]: fopen() in cwd: filename must start with ./ under safe mode
ID: 32503 Updated by: [EMAIL PROTECTED] Reported By: Bjorn dot Wiberg at its dot uu dot se -Status: Open +Status: Feedback Bug Type: Safe Mode/open_basedir Operating System: IBM AIX 5.2.0.0 ML5 PHP Version: 5CVS-2005-07-05 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip Previous Comments: [2005-07-05 10:21:38] Bjorn dot Wiberg at its dot uu dot se (Thanks for fixing the mpm_common crash, that problem is gone now.) With #define HAVE_BROKEN_GETCWD 1 in php_config.h, and having made sure that the path up to the directory where the file is to be created has sufficient permissions, I still get the same error: /apache/htdocs/bwiberg/test/safemode Warning: fopen(): Unable to access a.txt in /apache/htdocs/bwiberg/test/safemode/write.php on line 5 Warning: fopen(a.txt): failed to open stream: No such file or directory in /apache/htdocs/bwiberg/test/safemode/write.php on line 5 Having the read (r) permission off for the "test" directory along the way: Warning: fopen(): open_basedir restriction in effect. File(a.txt) is not within the allowed path(s): (.:/apache/php/lib/php/:/apache/htdocs/bwiberg/) in /apache/htdocs/bwiberg/test/safemode/write.php on line 5 Warning: fopen(a.txt): failed to open stream: Not owner in /apache/htdocs/bwiberg/test/safemode/write.php on line 5 Best regards, Björn [2005-05-09 14:15:53] Bjorn dot Wiberg at its dot uu dot se Hi again! I just tried the #define HAVE_BROKEN_GETCWD 1 trick from http://bugs.php.net/bug.php?id=32501, with PHP 5.0.4 (the "fixed" version) but that didn't help in this regard. I thought I would mention this. Best regards, Björn [2005-04-05 09:28:28] Bjorn dot Wiberg at its dot uu dot se Hi Tony! Thank you for your feedback! I'm afraid that absolute paths aren't a very viable solution to this, as that probably would break too many scripts, expecting it to be possible to "just" save a file to the current directory. Is the "PHP realpath hack" supposed to handle these kind of problems on AIX? Please let me know if I can help in any way! Best regards, Björn [2005-04-04 17:11:05] [EMAIL PROTECTED] Right, this is somehow concerned with broken realpath() on AIX. The problem is that we end up with relative path in php_checkuid_ex() function and it fails to check permissions for the directory. Of course, the easiest solution is to use absolute paths everywhere. [2005-04-01 16:32:32] Bjorn dot Wiberg at its dot uu dot se Tried php5-200503310630 (5.1.0-dev), but the problem is still present: /apache/htdocs/bwiberg/test/safemode Warning: fopen(): Unable to access a.txt in /apache/htdocs/bwiberg/test/safemode/write.php on line 5 Warning: fopen(a.txt): failed to open stream: No such file or directory in /apache/htdocs/bwiberg/test/safemode/write.php on line 5 (Whereas "./a.txt" works just fine.) Best regards, Björn 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/32503 -- Edit this bug report at http://bugs.php.net/?id=32503&edit=1
#32962 [Asn->Fbk]: Installer puts php.ini in wrong location
ID: 32962 Updated by: [EMAIL PROTECTED] Reported By: ash at theleys dot net -Status: Assigned +Status: Feedback Bug Type: IIS related Operating System: Windows Server 2003 PHP Version: 5.0.4 Assigned To: phildriscoll New Comment: Does this happen with the latest release? (5.1.1) Previous Comments: [2005-11-07 00:01:14] [EMAIL PROTECTED] Phil, there's the feedback you asked. (given same day, but you didn't notice?) [2005-05-09 11:38:37] ash at theleys dot net Under this comment are all the environment variables, - there isn't a "win" one, but "windir" is pointing to the correct folder. - This was installed with me using a terminal services session, but that's not been a problem before. (the comp. names have been changed here for privacy) ALLUSERSPROFILE=C:\Documents and Settings\All Users APPDATA=C:\Documents and Settings\Administrator\Application Data CLIENTNAME=CHANGEDTOPROTECTSERVER ClusterLog=C:\WINDOWS\Cluster\cluster.log CommonProgramFiles=C:\Program Files\Common Files COMPUTERNAME=CHANGEDTOPROTECTSERVER ComSpec=C:\WINDOWS\system32\cmd.exe HOMEDRIVE=C: HOMEPATH=\Documents and Settings\Administrator LOGONSERVER=\\HENRYV NUMBER_OF_PROCESSORS=4 OS=Windows_NT Path=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH PROCESSOR_ARCHITECTURE=x86 PROCESSOR_IDENTIFIER=x86 Family 15 Model 2 Stepping 9, GenuineIntel PROCESSOR_LEVEL=15 PROCESSOR_REVISION=0209 ProgramFiles=C:\Program Files PROMPT=$P$G SESSIONNAME=RDP-Tcp#1 SystemDrive=C: SystemRoot=C:\WINDOWS TEMP=C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\1 TMP=C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\1 USERDOMAIN=HENRYV USERNAME=Administrator USERPROFILE=C:\Documents and Settings\Administrator windir=C:\WINDOWS [2005-05-09 11:01:08] [EMAIL PROTECTED] I don't have Windows Server 2003, and I can't reproduce the problem on W2K Advanced Server (the only Windows machine I have). Can you tell me what the value of the WIN environment variable is when you are logged in as administrator? Thanks [2005-05-07 06:14:01] [EMAIL PROTECTED] Assigning to the author of the installer. [2005-05-06 13:18:01] ash at theleys dot net Description: Using the php-5.0.4-installer.exe puts php.ini into c:\docs&settings\administrator\WINDOWS\ - not in c:\windows, therefore it's not available, and causes "500" errors. - Found this out by parsing from php -i and noticing Configuration File (php.ini) Path was set wrongly. Expected result: phpinfo (or whatever the web page contains) Actual result: -- 500 CGI Error -- Edit this bug report at http://bugs.php.net/?id=32962&edit=1
#33073 [Asn->Fbk]: PHP Windows Installer does not set Verify File Exists for IIS 6.
ID: 33073 Updated by: [EMAIL PROTECTED] Reported By: webmaster at cyberdogtech dot com -Status: Assigned +Status: Feedback Bug Type: IIS related Operating System: Windows Server 2003 PHP Version: 5.0.4 Assigned To: phildriscoll New Comment: Does this happen with the latest release? (5.1.1) Previous Comments: [2005-11-07 00:01:42] [EMAIL PROTECTED] Phil, are you aware of this issue? [2005-05-20 10:34:06] [EMAIL PROTECTED] Assigned the person behind the installer.. =) [2005-05-20 00:31:02] webmaster at cyberdogtech dot com Description: I discovered this bug while using the PHP Windows Installer with 5.0.4 under IIS6 on Windows Server 2003 SP1. The installer adds the ISAPI extension to IIS for .php files, linking them to php-cgi.exe. The problem is, it does not set the option of "Verify that File Exists." This option causes IIS to validate the presence of the requested file. Without it set, as it stands now, php will always return an html page even for non-existent files! For example if I request www.website.com/nothing.php (a file which doesn't exist), PHP will still return empty HTML tags instead of the usual 404. By activating this IIS option, however, a 404 is returned properly instead of invoking PHP on the missing file name. -- Edit this bug report at http://bugs.php.net/?id=33073&edit=1
#33115 [Asn->Fbk]: Windows Install Silent Option breaks OS environment path variable
ID: 33115 Updated by: [EMAIL PROTECTED] Reported By: john dot jantjes at gmail dot com -Status: Assigned +Status: Feedback Bug Type: IIS related Operating System: Windows XP PHP Version: 5.0.4, 4.3.11 Assigned To: phildriscoll New Comment: Does this happen with the latest release? (5.1.1) Previous Comments: [2005-11-07 00:03:50] [EMAIL PROTECTED] Phil, have you checked this report yet..? [2005-05-24 04:20:36] john dot jantjes at gmail dot com If the installer is used normally, not silent, the issue does not appear. [2005-05-24 04:16:42] john dot jantjes at gmail dot com Description: I have been using the windows installer, with the "/s" option for a silent install, and have found that it breaks the OS environment variable. For example Instread of path being path=c:\windows;c:\windows\system32; . It becomes path=%SystemRoot%;%SystemRoot%\system32;.. It set the path variable to reference another variable, which just does not seem to work. Only the windows and windows system entries in path are effected. -- Edit this bug report at http://bugs.php.net/?id=33115&edit=1
#34340 [Asn->Bgs]: imagepstext returns T1Lib Error: Font ID Invalid in this Context
ID: 34340
Updated by: [EMAIL PROTECTED]
Reported By: brian at visionn dot com
-Status: Assigned
+Status: Bogus
Bug Type: GD related
Operating System: Windows NT
PHP Version: 5.1.0RC1
Assigned To: pajoye
New Comment:
Not PHP bug. Please report this to the T1 library author(s).
Previous Comments:
[2005-10-05 21:57:56] [EMAIL PROTECTED]
This is propably some threading issue with T1lib..
[2005-10-05 21:56:30] brian at visionn dot com
New version of test script with :
PATH_TO_FONT\font_file.pfb should be edited to work on the system
used.
I can't really post on online version, since each time you run the
script with an error, it would cause me to have to restart my web
server.
The easiest way to see the error would be to point the $font variable
to a non-existent pfb file, run it, then fix it to point to an existing
pfb file. Once the error has occurred, the function no longer works even
when the code is correct and the pfb file exists. Once you restart IIS,
it works again.
[2005-09-02 18:55:54] brian at visionn dot com
To reproduce, first run the code that work fine. Then introduce an
error, run it. Remove the error, run it. The clean code doesn't work
until a restart of IIS. There is a comment from 2001 in the docs about
this on the imagepstext page...so this might be a T1Lib error that it
can't recover from, and so wouldn't belong as a pure PHP bug(?)
[2005-09-02 18:49:14] brian at visionn dot com
apologies, here's a better version of the code with hardcoded values:
$font = imagepsloadfont("C:\\PATH_TO_FONT\\font_file.pfb");
$header_img = imagecreate(320, 20);
$font_color = imagecolorallocate($header_img, 42, 86, 143);
$bg_color = imagecolorallocate($header_img, 255, 255, 255);
imagefill($header_img, 0, 0, $bg_color);
imagepstext($header_img, "TEXT", $font, 18, $font_color,
$bg_color, 0, 16, 0, 0, 0, 16);
[2005-09-02 17:45:00] brian at visionn dot com
The error was fixed by restarting IIS.
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/34340
--
Edit this bug report at http://bugs.php.net/?id=34340&edit=1
#35711 [Opn->Asn]: [PATCH] ISO-8859 charset not correctly detected
ID: 35711
Updated by: [EMAIL PROTECTED]
Reported By: matteo at beccati dot com
-Status: Open
+Status: Assigned
Bug Type: mbstring related
Operating System: Debian GNU/Linux
PHP Version: 5.1.1
-Assigned To: moriyoshi
+Assigned To: hirokawa
New Comment:
Rui, can you check this out please?
Previous Comments:
[2005-12-19 09:00:50] matteo at beccati dot com
Oops, I just realized that I forgot the -u flag :)
Here is the downlaodable patch:
http://beccati.com/download/mbstring-patch-20051219.txt
[2005-12-19 08:48:47] [EMAIL PROTECTED]
Please provide any patches in unified diff format. (like the first
one). And downloadable somewhere.
[2005-12-16 23:50:13] matteo at beccati dot com
I've made a patch which seems to fix the issue. It basicly checks
filter status during judgement. Status seems to be != 0 only when it is
matching a multibyte character. I added anyway a fallback to the old
judgement routine, just in case no matching encoding is found.
Index: ext/mbstring/libmbfl/mbfl/mbfilter.c
===
RCS file: /repository/php-src/ext/mbstring/libmbfl/mbfl/mbfilter.c,v
retrieving revision 1.7.2.1
diff -u -r1.7.2.1 mbfilter.c
--- ext/mbstring/libmbfl/mbfl/mbfilter.c5 Nov 2005 04:49:57
- 1.7.2.1
+++ ext/mbstring/libmbfl/mbfl/mbfilter.c16 Dec 2005 22:46:26
-
@@ -575,12 +575,22 @@
for (i = 0; i < num; i++) {
filter = &flist[i];
- if (!filter->flag) {
+ if (!filter->flag && !filter->status) {
encoding = filter->encoding;
break;
}
}
+ if (!encoding) {
+ for (i = 0; i < num; i++) {
+ filter = &flist[i];
+ if (!filter->flag) {
+ encoding = filter->encoding;
+ break;
+ }
+ }
+ }
+
/* cleanup */
/* dtors should be called in reverse order */
i = num; while (--i >= 0) {
[2005-12-16 17:51:13] [EMAIL PROTECTED]
Moriyoshi, if ext/mbstring is not maintained anymore, please let us
know.
[2005-12-16 17:18:27] matteo at beccati dot com
Description:
I was evaluating the mbstring extension because of its capabilities to
filter and convert input parameter to the correct encoding. During my
test I found out that an ISO-8859-1 string which ends with an an
accented character is wrongly detected as UTF-8, even if it ends with
an incomplete multibyte character (using iconv to convert the string
raises such notice).
Also reproduced with PHP 4.3.11 on FreeBSD 4 and 5.0.2 on Win32.
Reproduce code:
---
Expected result:
Trying: string(7) "Test: à"
Notice: iconv(): Detected an incomplete multibyte character in input
string in test.php on line 13
Detected encoding: ISO-8859-1
Converted string:string(8) "Test: Ã "
Trying: string(8) "Test: àa"
Notice: iconv(): Detected an illegal character in input string in
/var/www/mbstring/test.php on line 13
Detected encoding: ISO-8859-1
Converted string:string(9) "Test: Ã a"
Actual result:
--
Trying: string(7) "Test: à"
Notice: iconv(): Detected an incomplete multibyte character in input
string in test.php on line 13
Detected encoding: UTF-8
Converted string:string(6) "Test: "
Trying: string(8) "Test: àa"
Notice: iconv(): Detected an illegal character in input string in
/var/www/mbstring/test.php on line 13
Detected encoding: ISO-8859-1
Converted string:string(9) "Test: Ã a"
--
Edit this bug report at http://bugs.php.net/?id=35711&edit=1
#27132 [Opn->Asn]: ncurses_getch() interrupted by receipt of a handled signal
ID: 27132
Updated by: [EMAIL PROTECTED]
Reported By: neuhauser at chello dot cz
-Status: Open
+Status: Assigned
Bug Type: ncurses related
Operating System: *
PHP Version: 5CVS, 4CVS (2004-02-25)
Assigned To: hholzgra
New Comment:
Hartmut: If you're not going to do anything about this, please
de-assign it with some comment. And preferrably move the whole
extension to PECL the same time..
Previous Comments:
[2004-02-03 09:51:52] neuhauser at chello dot cz
Description:
receipt of a signal interrupts ncurses_getch(), which
should never happen
curs_getch(3X):
The behavior of getch and friends in the presence
of handled signals is unspecified in the SVr4 and
XSI Curses documentation. Under historical curses
implementations, it varied depending on whether
the operating system's implementation of handled
signal receipt interrupts a read(2) call in
progress or not, and also (in some implementations)
depending on whether an input timeout or
non-blocking mode hsd been set.
Programmers concerned about portability should be
prepared for either of two cases: (a) signal
receipt does not interrupt getch; (b) signal
receipt interrupts getch and causes it to return
ERR with errno set to EINTR.
Under the ncurses implementation, handled signals
never interrupt getch.
(emphasis added)
Reproduce code:
---
compare the behavior of this PHP snippet
#include
#include
int c;
void sigalrm()
{
char s[40];
sprintf(s, "sigalrm: '%d'\n", c);
addstr(s);
refresh();
}
int main(int argc, char** argv)
{
initscr();
cbreak();
nl();
noecho();
signal(SIGALRM, sigalrm);
for (;;) {
alarm(1);
c = getch();
if ('q' == c) {
return 0;
}
}
endwin();
return 0;
}
Expected result:
I was expecting to see the same output as given by the C version:
single
sigalrm: '0'
line until next keypress, then the zero would be replaced with ascii
code of the pressed key
Actual result:
--
endless series of
sigalrm: '-1'
lines, which suggests that receipt of the alarm, although handled,
interrupts the getch() call which then returns ERR.
(as a sidenote, http://www.php.net/manual/en/ref.ncurses.php says "On
error ncurses functions return NCURSES_ERR", but said constant doesn't
exist in 4.3.3 or 4.3.4, both cli)
--
Edit this bug report at http://bugs.php.net/?id=27132&edit=1
#27132 [Asn->Opn]: ncurses_getch() interrupted by receipt of a handled signal
ID: 27132
Updated by: [EMAIL PROTECTED]
Reported By: neuhauser at chello dot cz
-Status: Assigned
+Status: Open
Bug Type: ncurses related
Operating System: *
PHP Version: 5CVS, 4CVS (2004-02-25)
Assigned To: hholzgra
Previous Comments:
[2004-02-03 09:51:52] neuhauser at chello dot cz
Description:
receipt of a signal interrupts ncurses_getch(), which
should never happen
curs_getch(3X):
The behavior of getch and friends in the presence
of handled signals is unspecified in the SVr4 and
XSI Curses documentation. Under historical curses
implementations, it varied depending on whether
the operating system's implementation of handled
signal receipt interrupts a read(2) call in
progress or not, and also (in some implementations)
depending on whether an input timeout or
non-blocking mode hsd been set.
Programmers concerned about portability should be
prepared for either of two cases: (a) signal
receipt does not interrupt getch; (b) signal
receipt interrupts getch and causes it to return
ERR with errno set to EINTR.
Under the ncurses implementation, handled signals
never interrupt getch.
(emphasis added)
Reproduce code:
---
compare the behavior of this PHP snippet
#include
#include
int c;
void sigalrm()
{
char s[40];
sprintf(s, "sigalrm: '%d'\n", c);
addstr(s);
refresh();
}
int main(int argc, char** argv)
{
initscr();
cbreak();
nl();
noecho();
signal(SIGALRM, sigalrm);
for (;;) {
alarm(1);
c = getch();
if ('q' == c) {
return 0;
}
}
endwin();
return 0;
}
Expected result:
I was expecting to see the same output as given by the C version:
single
sigalrm: '0'
line until next keypress, then the zero would be replaced with ascii
code of the pressed key
Actual result:
--
endless series of
sigalrm: '-1'
lines, which suggests that receipt of the alarm, although handled,
interrupts the getch() call which then returns ERR.
(as a sidenote, http://www.php.net/manual/en/ref.ncurses.php says "On
error ncurses functions return NCURSES_ERR", but said constant doesn't
exist in 4.3.3 or 4.3.4, both cli)
--
Edit this bug report at http://bugs.php.net/?id=27132&edit=1
#35711 [Fbk->Opn]: [PATCH] ISO-8859 charset not correctly detected
ID: 35711
User updated by: matteo at beccati dot com
Reported By: matteo at beccati dot com
-Status: Feedback
+Status: Open
Bug Type: mbstring related
Operating System: Debian GNU/Linux
PHP Version: 5.1.1
Assigned To: moriyoshi
New Comment:
Oops, I just realized that I forgot the -u flag :)
Here is the downlaodable patch:
http://beccati.com/download/mbstring-patch-20051219.txt
Previous Comments:
[2005-12-19 08:48:47] [EMAIL PROTECTED]
Please provide any patches in unified diff format. (like the first
one). And downloadable somewhere.
[2005-12-17 10:13:11] matteo at beccati dot com
Improved patch to also work with mbstring.encoding_translation
enabled.
Index: ext/mbstring/libmbfl/mbfl/mbfilter.c
===
RCS file: /repository/php-src/ext/mbstring/libmbfl/mbfl/mbfilter.c,v
retrieving revision 1.7.2.1
diff -r1.7.2.1 mbfilter.c
443c443
< if (!filter->flag) {
---
> if (!filter->flag && !filter->status) {
447a448,458
>
> if (encoding == mbfl_no_encoding_invalid) {
> n = identd->filter_list_size - 1;
> while (n >= 0) {
> filter = identd->filter_list[n];
> if (!filter->flag) {
> encoding =
filter->encoding->no_encoding;
> }
> n--;
> }
> }
578c589
< if (!filter->flag) {
---
> if (!filter->flag && !filter->status) {
583a595,604
> if (!encoding) {
> for (i = 0; i < num; i++) {
> filter = &flist[i];
> if (!filter->flag) {
> encoding = filter->encoding;
> break;
> }
> }
> }
>
[2005-12-16 23:50:13] matteo at beccati dot com
I've made a patch which seems to fix the issue. It basicly checks
filter status during judgement. Status seems to be != 0 only when it is
matching a multibyte character. I added anyway a fallback to the old
judgement routine, just in case no matching encoding is found.
Index: ext/mbstring/libmbfl/mbfl/mbfilter.c
===
RCS file: /repository/php-src/ext/mbstring/libmbfl/mbfl/mbfilter.c,v
retrieving revision 1.7.2.1
diff -u -r1.7.2.1 mbfilter.c
--- ext/mbstring/libmbfl/mbfl/mbfilter.c5 Nov 2005 04:49:57
- 1.7.2.1
+++ ext/mbstring/libmbfl/mbfl/mbfilter.c16 Dec 2005 22:46:26
-
@@ -575,12 +575,22 @@
for (i = 0; i < num; i++) {
filter = &flist[i];
- if (!filter->flag) {
+ if (!filter->flag && !filter->status) {
encoding = filter->encoding;
break;
}
}
+ if (!encoding) {
+ for (i = 0; i < num; i++) {
+ filter = &flist[i];
+ if (!filter->flag) {
+ encoding = filter->encoding;
+ break;
+ }
+ }
+ }
+
/* cleanup */
/* dtors should be called in reverse order */
i = num; while (--i >= 0) {
[2005-12-16 17:51:13] [EMAIL PROTECTED]
Moriyoshi, if ext/mbstring is not maintained anymore, please let us
know.
[2005-12-16 17:18:27] matteo at beccati dot com
Description:
I was evaluating the mbstring extension because of its capabilities to
filter and convert input parameter to the correct encoding. During my
test I found out that an ISO-8859-1 string which ends with an an
accented character is wrongly detected as UTF-8, even if it ends with
an incomplete multibyte character (using iconv to convert the string
raises such notice).
Also reproduced with PHP 4.3.11 on FreeBSD 4 and 5.0.2 on Win32.
Reproduce code:
---
Expected result:
Trying: string(7) "Test: à"
Notice: iconv(): Detected an incomplete multibyte character in input
string in test.php on line 13
Detected encoding: ISO-8859-1
Converted string:string(8) "Test: Ã "
Trying: string(8) "Test: àa"
Notice: iconv(): Detected an
