Bug #51983 [Com]: [fpm sapi] pm.status_path not working when cgi.fix_pathinfo=1
Edit report at http://bugs.php.net/bug.php?id=51983&edit=1 ID: 51983 Comment by: f...@php.net Reported by: konstantin at symbi dot org Summary: [fpm sapi] pm.status_path not working when cgi.fix_pathinfo=1 Status: Assigned Type: Bug Package: FPM related Operating System: Any PHP Version: 5.3SVN-2010-06-03 (snap) Assigned To: fat New Comment: I'm asking about Apache, to be certain not to ban some webservers from using FPM. According to http://www.fastcgi.com/drupal/node/3, we have to make sure that FPM is compliant with all of the following webservers: Apache Microsoft IIS Microsoft IIS (second generation) SunOne Lighttpd Premium thttpd http MyServer Pi3Web WebSTAR (Mac OS) Nginx Cherokee Previous Comments: [2010-06-04 08:52:49] konstantin at symbi dot org 99% of fpm installations are with nginx or lighty, using fpm sapi with non-FSM webservers is at least very strange. But I have just checked it with Apache+mod_fastcgi in a simplest configuration: DocumentRoot "/var/www" FastCgiExternalServer /var/www -socket /tmp/php-fpm.sock Options FollowSymLinks +ExecCGI AllowOverride All Order Allow,Deny Allow from all and it works OK. The patch contains comments in the top of the new init_request_info() implementation. It describes why fastcgi parameters are mapped to the script filename in this way, and it was chosen after examining CGI specs, typical fpm configurations, and common sense. BTW, those webservers like old IIS versions with buggy cgi implementations which required that awkward way of guessing what they meant, for which the original implementation of init_request_info() was designed, do not support remote FastCGI at all. [2010-06-04 08:25:19] f...@php.net Have you tried your patch with other webservers than nginx and lighttpd ? [2010-06-04 06:32:12] sergo_s at bk dot ru I met problem "No input file specified" in the configuration of lighttpd 1.4.26 + php-5.3.2 + fastcgi/php-fpm when requesting addresses like index.php/myMethod/ (kohanaframework based site). I found that $_SERVER[PATH_INFO] is NULL. (More about my problem in this post: http://phpclub.ru/talk/showthread.php?s=&postid=902382 (russian)) This patch solved the problem. Thanks. [2010-06-03 04:42:33] konstantin at symbi dot org Description: FPM status does not work when cgi.fix_pathinfo = 1, with the default nginx configuration for php (default fastcgi_params + SCRIPT_FILENAME added). The problems is that in fpm_main.c, here: if (!strcasecmp(SG(request_info).request_method, "GET") && fpm_status_handle_status(SG(request_info).request_uri, ... SG(request_info).request_uri is sometimes NULL depending on the trickiest things which happen when cgi.fix_pathinfo = 1. I have examined the code of init_request_info() which runs when cgi.fix_pathinfo = 1, and I found out that this part of code is legacy part from the CGI SAPI, it is was designed to fix problems with a lots of broken CGI implementations. It was reasonable for CGI to get the things working independent on speed, but the 'bruteforce' approach used is not too good for FPM SAPI which is commonly used on high-bandwidth sites. More, PHP introduces non-standard "SCRIPT_FILENAME" fastcgi env; it is not hard to add it to configuration of flexible servers like nginx (by using "fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name" in its configuration), but it can cause problems with such servers as lighttpd where all the fastcgi parameters are hardcoded (I've seen people on forums complaining thay get 'no input file' with nginx+fpm and they found no way to fix it). So, I have found the fix_pathinfo part is written in a hard to understand and difficult to fix way, and that is is really not required for FPM SAPI, and that it slows it down. System administrators who configure FSM webservers and use FPM sapi are usually experianced and for them it would be preferable to have strict and simple logic rather then some magic which can potentially slow things down a lot. So i have rewritten init_request_info(), the the suggested patch is attached. It logic of detection script_filename is much simpler: if SCRIPT_FILENAME is defined, use it, else if both DOCUMENT_ROOT and SCRIPT_NAME are defined, concat them and use (should fix all the problems with lighty etc); else if PATH_TRALSLATED is defined, use it as script_filename; else we do not know the script_filename. And, of course, it fixes the problem with pm.status_path I
Bug #51983 [Asn]: [fpm sapi] pm.status_path not working when cgi.fix_pathinfo=1
Edit report at http://bugs.php.net/bug.php?id=51983&edit=1 ID: 51983 User updated by: konstantin at symbi dot org Reported by: konstantin at symbi dot org Summary: [fpm sapi] pm.status_path not working when cgi.fix_pathinfo=1 Status: Assigned Type: Bug Package: FPM related Operating System: Any PHP Version: 5.3SVN-2010-06-03 (snap) Assigned To: fat New Comment: 99% of fpm installations are with nginx or lighty, using fpm sapi with non-FSM webservers is at least very strange. But I have just checked it with Apache+mod_fastcgi in a simplest configuration: DocumentRoot "/var/www" FastCgiExternalServer /var/www -socket /tmp/php-fpm.sock Options FollowSymLinks +ExecCGI AllowOverride All Order Allow,Deny Allow from all and it works OK. The patch contains comments in the top of the new init_request_info() implementation. It describes why fastcgi parameters are mapped to the script filename in this way, and it was chosen after examining CGI specs, typical fpm configurations, and common sense. BTW, those webservers like old IIS versions with buggy cgi implementations which required that awkward way of guessing what they meant, for which the original implementation of init_request_info() was designed, do not support remote FastCGI at all. Previous Comments: [2010-06-04 08:25:19] f...@php.net Have you tried your patch with other webservers than nginx and lighttpd ? [2010-06-04 06:32:12] sergo_s at bk dot ru I met problem "No input file specified" in the configuration of lighttpd 1.4.26 + php-5.3.2 + fastcgi/php-fpm when requesting addresses like index.php/myMethod/ (kohanaframework based site). I found that $_SERVER[PATH_INFO] is NULL. (More about my problem in this post: http://phpclub.ru/talk/showthread.php?s=&postid=902382 (russian)) This patch solved the problem. Thanks. [2010-06-03 04:42:33] konstantin at symbi dot org Description: FPM status does not work when cgi.fix_pathinfo = 1, with the default nginx configuration for php (default fastcgi_params + SCRIPT_FILENAME added). The problems is that in fpm_main.c, here: if (!strcasecmp(SG(request_info).request_method, "GET") && fpm_status_handle_status(SG(request_info).request_uri, ... SG(request_info).request_uri is sometimes NULL depending on the trickiest things which happen when cgi.fix_pathinfo = 1. I have examined the code of init_request_info() which runs when cgi.fix_pathinfo = 1, and I found out that this part of code is legacy part from the CGI SAPI, it is was designed to fix problems with a lots of broken CGI implementations. It was reasonable for CGI to get the things working independent on speed, but the 'bruteforce' approach used is not too good for FPM SAPI which is commonly used on high-bandwidth sites. More, PHP introduces non-standard "SCRIPT_FILENAME" fastcgi env; it is not hard to add it to configuration of flexible servers like nginx (by using "fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name" in its configuration), but it can cause problems with such servers as lighttpd where all the fastcgi parameters are hardcoded (I've seen people on forums complaining thay get 'no input file' with nginx+fpm and they found no way to fix it). So, I have found the fix_pathinfo part is written in a hard to understand and difficult to fix way, and that is is really not required for FPM SAPI, and that it slows it down. System administrators who configure FSM webservers and use FPM sapi are usually experianced and for them it would be preferable to have strict and simple logic rather then some magic which can potentially slow things down a lot. So i have rewritten init_request_info(), the the suggested patch is attached. It logic of detection script_filename is much simpler: if SCRIPT_FILENAME is defined, use it, else if both DOCUMENT_ROOT and SCRIPT_NAME are defined, concat them and use (should fix all the problems with lighty etc); else if PATH_TRALSLATED is defined, use it as script_filename; else we do not know the script_filename. And, of course, it fixes the problem with pm.status_path I started with. Test script: --- N/A Expected result: N/A Actual result: -- N/A -- Edit this bug report at http://bugs.php.net/bug.php?id=51983&edit=1
Bug #51266 [Fbk]: stat failed on cifs-mounted files
Edit report at http://bugs.php.net/bug.php?id=51266&edit=1 ID: 51266 Updated by: m...@php.net Reported by: dctucker at hotmail dot com Summary: stat failed on cifs-mounted files Status: Feedback Type: Bug Package: Filesystem function related Operating System: Arch Linux (current) PHP Version: 5.3.2 New Comment: Cannot reproduce, still works fine here. When you edit your report, please re-open it, too. Previous Comments: [2010-06-03 20:37:31] dctucker at hotmail dot com The mount command lacks noserverino: $ tail -n 1 /etc/fstab //theword/d /mnt/theword cifs nocase,file_mode=0664,dir_mode=0775,username=Administrator%,uid=nobody 0 0 [2010-05-21 11:23:44] m...@php.net How does the mount command look like, so that it fails? [2010-05-20 21:54:15] dctucker at hotmail dot com Mike, Using the 'noserverino' workaround does mitigate the problem, but it does not address the underlying issue. [2010-05-20 12:19:16] m...@php.net Works fine here too, so I assume it's not a PHP bug. [2010-03-24 20:05:42] mail at daniel-berlin dot de Adding cifs option "noserverino" solves the problem. 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/bug.php?id=51266 -- Edit this bug report at http://bugs.php.net/bug.php?id=51266&edit=1
Bug #51983 [Com]: [fpm sapi] pm.status_path not working when cgi.fix_pathinfo=1
Edit report at http://bugs.php.net/bug.php?id=51983&edit=1 ID: 51983 Comment by: f...@php.net Reported by: konstantin at symbi dot org Summary: [fpm sapi] pm.status_path not working when cgi.fix_pathinfo=1 Status: Assigned Type: Bug Package: FPM related Operating System: Any PHP Version: 5.3SVN-2010-06-03 (snap) Assigned To: fat New Comment: Have you tried your patch with other webservers than nginx and lighttpd ? Previous Comments: [2010-06-04 06:32:12] sergo_s at bk dot ru I met problem "No input file specified" in the configuration of lighttpd 1.4.26 + php-5.3.2 + fastcgi/php-fpm when requesting addresses like index.php/myMethod/ (kohanaframework based site). I found that $_SERVER[PATH_INFO] is NULL. (More about my problem in this post: http://phpclub.ru/talk/showthread.php?s=&postid=902382 (russian)) This patch solved the problem. Thanks. [2010-06-03 04:42:33] konstantin at symbi dot org Description: FPM status does not work when cgi.fix_pathinfo = 1, with the default nginx configuration for php (default fastcgi_params + SCRIPT_FILENAME added). The problems is that in fpm_main.c, here: if (!strcasecmp(SG(request_info).request_method, "GET") && fpm_status_handle_status(SG(request_info).request_uri, ... SG(request_info).request_uri is sometimes NULL depending on the trickiest things which happen when cgi.fix_pathinfo = 1. I have examined the code of init_request_info() which runs when cgi.fix_pathinfo = 1, and I found out that this part of code is legacy part from the CGI SAPI, it is was designed to fix problems with a lots of broken CGI implementations. It was reasonable for CGI to get the things working independent on speed, but the 'bruteforce' approach used is not too good for FPM SAPI which is commonly used on high-bandwidth sites. More, PHP introduces non-standard "SCRIPT_FILENAME" fastcgi env; it is not hard to add it to configuration of flexible servers like nginx (by using "fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name" in its configuration), but it can cause problems with such servers as lighttpd where all the fastcgi parameters are hardcoded (I've seen people on forums complaining thay get 'no input file' with nginx+fpm and they found no way to fix it). So, I have found the fix_pathinfo part is written in a hard to understand and difficult to fix way, and that is is really not required for FPM SAPI, and that it slows it down. System administrators who configure FSM webservers and use FPM sapi are usually experianced and for them it would be preferable to have strict and simple logic rather then some magic which can potentially slow things down a lot. So i have rewritten init_request_info(), the the suggested patch is attached. It logic of detection script_filename is much simpler: if SCRIPT_FILENAME is defined, use it, else if both DOCUMENT_ROOT and SCRIPT_NAME are defined, concat them and use (should fix all the problems with lighty etc); else if PATH_TRALSLATED is defined, use it as script_filename; else we do not know the script_filename. And, of course, it fixes the problem with pm.status_path I started with. Test script: --- N/A Expected result: N/A Actual result: -- N/A -- Edit this bug report at http://bugs.php.net/bug.php?id=51983&edit=1
Bug #51983 [Com]: [fpm sapi] pm.status_path not working when cgi.fix_pathinfo=1
Edit report at http://bugs.php.net/bug.php?id=51983&edit=1 ID: 51983 Comment by: sergo_s at bk dot ru Reported by: konstantin at symbi dot org Summary: [fpm sapi] pm.status_path not working when cgi.fix_pathinfo=1 Status: Assigned Type: Bug Package: FPM related Operating System: Any PHP Version: 5.3SVN-2010-06-03 (snap) Assigned To: fat New Comment: I met problem "No input file specified" in the configuration of lighttpd 1.4.26 + php-5.3.2 + fastcgi/php-fpm when requesting addresses like index.php/myMethod/ (kohanaframework based site). I found that $_SERVER[PATH_INFO] is NULL. (More about my problem in this post: http://phpclub.ru/talk/showthread.php?s=&postid=902382 (russian)) This patch solved the problem. Thanks. Previous Comments: [2010-06-03 04:42:33] konstantin at symbi dot org Description: FPM status does not work when cgi.fix_pathinfo = 1, with the default nginx configuration for php (default fastcgi_params + SCRIPT_FILENAME added). The problems is that in fpm_main.c, here: if (!strcasecmp(SG(request_info).request_method, "GET") && fpm_status_handle_status(SG(request_info).request_uri, ... SG(request_info).request_uri is sometimes NULL depending on the trickiest things which happen when cgi.fix_pathinfo = 1. I have examined the code of init_request_info() which runs when cgi.fix_pathinfo = 1, and I found out that this part of code is legacy part from the CGI SAPI, it is was designed to fix problems with a lots of broken CGI implementations. It was reasonable for CGI to get the things working independent on speed, but the 'bruteforce' approach used is not too good for FPM SAPI which is commonly used on high-bandwidth sites. More, PHP introduces non-standard "SCRIPT_FILENAME" fastcgi env; it is not hard to add it to configuration of flexible servers like nginx (by using "fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name" in its configuration), but it can cause problems with such servers as lighttpd where all the fastcgi parameters are hardcoded (I've seen people on forums complaining thay get 'no input file' with nginx+fpm and they found no way to fix it). So, I have found the fix_pathinfo part is written in a hard to understand and difficult to fix way, and that is is really not required for FPM SAPI, and that it slows it down. System administrators who configure FSM webservers and use FPM sapi are usually experianced and for them it would be preferable to have strict and simple logic rather then some magic which can potentially slow things down a lot. So i have rewritten init_request_info(), the the suggested patch is attached. It logic of detection script_filename is much simpler: if SCRIPT_FILENAME is defined, use it, else if both DOCUMENT_ROOT and SCRIPT_NAME are defined, concat them and use (should fix all the problems with lighty etc); else if PATH_TRALSLATED is defined, use it as script_filename; else we do not know the script_filename. And, of course, it fixes the problem with pm.status_path I started with. Test script: --- N/A Expected result: N/A Actual result: -- N/A -- Edit this bug report at http://bugs.php.net/bug.php?id=51983&edit=1
Bug #51991 [Com]: spl_autoload and *nix support with namespace
Edit report at http://bugs.php.net/bug.php?id=51991&edit=1
ID: 51991
Comment by: grummfy at gmail dot com
Reported by: grummfy at gmail dot com
Summary: spl_autoload and *nix support with namespace
Status: Closed
Type: Bug
Package: SPL related
Operating System: linux, mac, *nix
PHP Version: 5.3.2
Assigned To: felipe
New Comment:
thanks
Previous Comments:
[2010-06-04 02:10:20] fel...@php.net
This bug has been fixed in SVN.
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.
[2010-06-04 02:10:18] fel...@php.net
Automatic comment from SVN on behalf of felipe
Revision: http://svn.php.net/viewvc/?view=revision&revision=300176
Log: - Fixed bug #51991 (spl_autoload and *nix support with namespace)
[2010-06-03 19:23:59] grummfy at gmail dot com
Description:
On windows systems you can use spl_autload to load namespaced class and
it works!
On *nix system you can't!
Tested on linux (ubuntu 10.04 64 bit) with package : php5
5.3.2-1ubuntu4.2
You can test the next script on a windows and on a linux or a mac.
Test script:
---
create a file called index.php
--
use My\Framework\Test;
spl_autoload_register();
$test = new Test();
echo $test;
--
Another file in a subdir My/Framework called Test.php
--
namespace My\Framework;
class Test
{
public function __toString()
{
return 'hi';
}
}
--
Expected result:
Expected result :
script that produce :
hi
Actual result:
--
windows:
hi
Linux:
Fatal error: spl_autoload() [function.spl-autoload]: Class
My\Framework\Test could not be loaded in /.../index.php on line 7
--
Edit this bug report at http://bugs.php.net/bug.php?id=51991&edit=1
Bug #51983 [Opn->Asn]: [fpm sapi] pm.status_path not working when cgi.fix_pathinfo=1
Edit report at http://bugs.php.net/bug.php?id=51983&edit=1 ID: 51983 Updated by: fel...@php.net Reported by: konstantin at symbi dot org Summary: [fpm sapi] pm.status_path not working when cgi.fix_pathinfo=1 -Status: Open +Status: Assigned Type: Bug -Package: CGI related +Package: FPM related Operating System: Any PHP Version: 5.3SVN-2010-06-03 (snap) -Assigned To: +Assigned To: fat Previous Comments: [2010-06-03 04:42:33] konstantin at symbi dot org Description: FPM status does not work when cgi.fix_pathinfo = 1, with the default nginx configuration for php (default fastcgi_params + SCRIPT_FILENAME added). The problems is that in fpm_main.c, here: if (!strcasecmp(SG(request_info).request_method, "GET") && fpm_status_handle_status(SG(request_info).request_uri, ... SG(request_info).request_uri is sometimes NULL depending on the trickiest things which happen when cgi.fix_pathinfo = 1. I have examined the code of init_request_info() which runs when cgi.fix_pathinfo = 1, and I found out that this part of code is legacy part from the CGI SAPI, it is was designed to fix problems with a lots of broken CGI implementations. It was reasonable for CGI to get the things working independent on speed, but the 'bruteforce' approach used is not too good for FPM SAPI which is commonly used on high-bandwidth sites. More, PHP introduces non-standard "SCRIPT_FILENAME" fastcgi env; it is not hard to add it to configuration of flexible servers like nginx (by using "fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name" in its configuration), but it can cause problems with such servers as lighttpd where all the fastcgi parameters are hardcoded (I've seen people on forums complaining thay get 'no input file' with nginx+fpm and they found no way to fix it). So, I have found the fix_pathinfo part is written in a hard to understand and difficult to fix way, and that is is really not required for FPM SAPI, and that it slows it down. System administrators who configure FSM webservers and use FPM sapi are usually experianced and for them it would be preferable to have strict and simple logic rather then some magic which can potentially slow things down a lot. So i have rewritten init_request_info(), the the suggested patch is attached. It logic of detection script_filename is much simpler: if SCRIPT_FILENAME is defined, use it, else if both DOCUMENT_ROOT and SCRIPT_NAME are defined, concat them and use (should fix all the problems with lighty etc); else if PATH_TRALSLATED is defined, use it as script_filename; else we do not know the script_filename. And, of course, it fixes the problem with pm.status_path I started with. Test script: --- N/A Expected result: N/A Actual result: -- N/A -- Edit this bug report at http://bugs.php.net/bug.php?id=51983&edit=1
Bug #51991 [Opn->Csd]: spl_autoload and *nix support with namespace
Edit report at http://bugs.php.net/bug.php?id=51991&edit=1
ID: 51991
Updated by: fel...@php.net
Reported by: grummfy at gmail dot com
Summary: spl_autoload and *nix support with namespace
-Status: Open
+Status: Closed
Type: Bug
Package: SPL related
Operating System: linux, mac, *nix
PHP Version: 5.3.2
-Assigned To:
+Assigned To: felipe
New Comment:
This bug has been fixed in SVN.
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:
[2010-06-04 02:10:18] fel...@php.net
Automatic comment from SVN on behalf of felipe
Revision: http://svn.php.net/viewvc/?view=revision&revision=300176
Log: - Fixed bug #51991 (spl_autoload and *nix support with namespace)
[2010-06-03 19:23:59] grummfy at gmail dot com
Description:
On windows systems you can use spl_autload to load namespaced class and
it works!
On *nix system you can't!
Tested on linux (ubuntu 10.04 64 bit) with package : php5
5.3.2-1ubuntu4.2
You can test the next script on a windows and on a linux or a mac.
Test script:
---
create a file called index.php
--
use My\Framework\Test;
spl_autoload_register();
$test = new Test();
echo $test;
--
Another file in a subdir My/Framework called Test.php
--
namespace My\Framework;
class Test
{
public function __toString()
{
return 'hi';
}
}
--
Expected result:
Expected result :
script that produce :
hi
Actual result:
--
windows:
hi
Linux:
Fatal error: spl_autoload() [function.spl-autoload]: Class
My\Framework\Test could not be loaded in /.../index.php on line 7
--
Edit this bug report at http://bugs.php.net/bug.php?id=51991&edit=1
[PHP-BUG] Req #51993 [NEW]: DateTime::getLastErrors should be an instance method, not static
From: Operating system: OS X, Centos 5 PHP version: 5.3.2 Package: Date/time related Bug Type: Feature/Change Request Bug description:DateTime::getLastErrors should be an instance method, not static Description: When using the DateTime class, it would make more sense to have getLastErrors be an instance method rather than a static method. That way, when creating a series of DateTime objects, you can check each one individually for errors. Currently it works as _documented_, but not in a very logical/useful way. Alternately, a getErrors() instance method that could sit alongside the getLastErrors() static method would be just as useful. Test script: --- getLastErrors()); } Expected result: Array ( [warning_count] => 0 [warnings] => Array ( ) [error_count] => 0 [errors] => Array ( ) ) Array ( [warning_count] => 0 [warnings] => Array ( ) [error_count] => 0 [errors] => Array ( ) ) Array ( [warning_count] => 1 [warnings] => Array ( [10] => The parsed date was invalid ) [error_count] => 0 [errors] => Array ( ) ) Array ( [warning_count] => 0 [warnings] => Array ( ) [error_count] => 0 [errors] => Array ( ) ) Actual result: -- Array ( [warning_count] => 0 [warnings] => Array ( ) [error_count] => 0 [errors] => Array ( ) ) Array ( [warning_count] => 0 [warnings] => Array ( ) [error_count] => 0 [errors] => Array ( ) ) Array ( [warning_count] => 0 [warnings] => Array ( ) [error_count] => 0 [errors] => Array ( ) ) Array ( [warning_count] => 0 [warnings] => Array ( ) [error_count] => 0 [errors] => Array ( ) ) -- Edit bug report at http://bugs.php.net/bug.php?id=51993&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51993&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51993&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=51993&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=51993&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51993&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51993&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51993&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51993&r=needscript Try newer version: http://bugs.php.net/fix.php?id=51993&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51993&r=support Expected behavior: http://bugs.php.net/fix.php?id=51993&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51993&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51993&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51993&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51993&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51993&r=dst IIS Stability: http://bugs.php.net/fix.php?id=51993&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51993&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51993&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51993&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51993&r=mysqlcfg
Req #51622 [Com]: ArrayObject::offsetGet should return a reference
Edit report at http://bugs.php.net/bug.php?id=51622&edit=1 ID: 51622 Comment by: andrewm dot finewolf at gmail dot com Reported by: oliver dot graetz at gmx dot de Summary: ArrayObject::offsetGet should return a reference Status: Open Type:Feature/Change Request Package: SPL related PHP Version: 5.2.13 New Comment: Arrays in PHP contains references to primitive types and reference types. Which basically means that if you are post-incrementing an element, well, it actually works. Why is ArrayAccess::offsetGet() returns by value instead of by reference? Wasn't ArrayAccess created to emulate an array? This is a major inconsistency in the platform and makes this whole interface pretty useless. This isn't an engine limitation. __get(), __set(), __isset(), __unset() is returning values by reference without any problems. Why can't ArrayAccess (when it does pretty much the same thing?) Can ArrayAccess::offsetGet() return by reference (or at the very least create a second interface, "ArrayAccessRef", for this)? Previous Comments: [2010-04-27 10:02:34] col...@php.net This is actually a feature request. To be backward compatible, we would need to have a new interface, and obviously a new interface only to solve that reference thing is painful. The immediate solution is to return an ArrayObject itself, which means that indirect modifications will work. [2010-04-21 13:35:50] oliver dot graetz at gmx dot de Description: This bug refers to my report filed under http://bugs.php.net/bug.php?id=34783 which is now more than four years old. In the meantime I found out that using ArrayObject instead of the test class the $t['huba'][]='three'; actually works, thanks to the SPL using its "implemented in C advantage" to circumvent the problem. Actually, it works until the programmer decides to inherit from ArrayObject and overwrite offsetGet(). Then the problem of the offsetGet() method not returning by reference is back. Back in 2005 you were very quick to flag the report as BOGUS, but a look at the source code of "zend_interfaces.c" proves that there is in fact a problem: ZEND_BEGIN_ARG_INFO_EX(arginfo_arrayaccess_offset_get, 0, 0, 1) /* actually this should be return by ref but atm cannot be */ The best way of dealing with this is not to mark it as BOGUS and deny that there is a problem. It would be admitting the fault and perhaps introducing an alternative NewArrayAccess interface that defines &offsetGet(). So future code can use it without breaking old implementations. Test script: --- Array ( [0] => one [1] => two [2] => three ) ) Test2 Object ( [huba] => Array ( [0] => one [1] => two [2] => three ) ) Actual result: -- Test1 Object ( [huba] => Array ( [0] => one [1] => two [2] => three ) ) Notice: Indirect modification of overloaded element of Test2 has no effect in F:\huba.php on line 17 Test2 Object ( [huba] => Array ( [0] => one [1] => two ) ) -- Edit this bug report at http://bugs.php.net/bug.php?id=51622&edit=1
Req #51992 [Bgs]: ArrayAccess and references
Edit report at http://bugs.php.net/bug.php?id=51992&edit=1
ID: 51992
User updated by: andrewm dot finewolf at gmail dot com
Reported by: andrewm dot finewolf at gmail dot com
Summary: ArrayAccess and references
Status: Bogus
Type: Feature/Change Request
Package: SPL related
Operating System: Irrelevant
PHP Version: Irrelevant
New Comment:
And none of those where filled in "Feature/Change Request"...
Previous Comments:
[2010-06-03 23:28:19] johan...@php.net
Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same.
Thank you for your interest in PHP.
This limitation is subject of a few other bugs and discussions.
[2010-06-03 23:19:13] andrewm dot finewolf at gmail dot com
Description:
Arrays in PHP contains references to primitive types and reference
types. Which basically means that if you are post-incrementing an
element, well, it actually works.
Why is ArrayAccess::offsetGet() returns by value instead of by
reference? Wasn't ArrayAccess created to emulate an array? This is a
major inconsistency in the platform and makes this whole interface
pretty useless. This isn't an engine limitation. __get(), __set(),
__isset(), __unset() is returning values by reference without any
problems. Why can't ArrayAccess (when it does pretty much the same
thing?)
Can ArrayAccess::offsetGet() return by reference (or at the very least
create a second interface, "ArrayAccessRef", for this)?
Test script:
---
container[$name] = $value;
}
public function offsetExists($name) {
return isset($this->container[$name]);
}
public function offsetUnset($name) {
unset($this->container[$name]);
}
public function offsetGet($name) {
return isset($this->container[$name]) ? $this->container[$name]
:
null;
}
}
class ObjectTest {
private $container = array();
public function __set($name, $value) {
$this->container[$name] = $value;
}
public function __isset($name) {
return isset($this->container[$name]);
}
public function __unset($name) {
unset($this->container[$name]);
}
public function __get($name) {
return isset($this->container[$name]) ? $this->container[$name]
:
null;
}
}
$array = array();
$array['counter'] = 0;
$array['counter']++;
echo $array['counter'] . "\n";
$objArray = new ArrayTest();
$objArray['counter'] = 0;
$objArray['counter']++;
echo $objArray['counter'] . "\n";
$objAccess = new ObjectTest();
$objAccess->counter = 0;
$objAccess->counter++;
echo $objAccess->counter . "\n";
Expected result:
1
1
1
Actual result:
--
1
0
1
--
Edit this bug report at http://bugs.php.net/bug.php?id=51992&edit=1
Req #51992 [Opn->Bgs]: ArrayAccess and references
Edit report at http://bugs.php.net/bug.php?id=51992&edit=1
ID: 51992
Updated by: johan...@php.net
Reported by: andrewm dot finewolf at gmail dot com
Summary: ArrayAccess and references
-Status: Open
+Status: Bogus
Type: Feature/Change Request
Package: SPL related
Operating System: Irrelevant
PHP Version: Irrelevant
New Comment:
Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same.
Thank you for your interest in PHP.
This limitation is subject of a few other bugs and discussions.
Previous Comments:
[2010-06-03 23:19:13] andrewm dot finewolf at gmail dot com
Description:
Arrays in PHP contains references to primitive types and reference
types. Which basically means that if you are post-incrementing an
element, well, it actually works.
Why is ArrayAccess::offsetGet() returns by value instead of by
reference? Wasn't ArrayAccess created to emulate an array? This is a
major inconsistency in the platform and makes this whole interface
pretty useless. This isn't an engine limitation. __get(), __set(),
__isset(), __unset() is returning values by reference without any
problems. Why can't ArrayAccess (when it does pretty much the same
thing?)
Can ArrayAccess::offsetGet() return by reference (or at the very least
create a second interface, "ArrayAccessRef", for this)?
Test script:
---
container[$name] = $value;
}
public function offsetExists($name) {
return isset($this->container[$name]);
}
public function offsetUnset($name) {
unset($this->container[$name]);
}
public function offsetGet($name) {
return isset($this->container[$name]) ? $this->container[$name]
:
null;
}
}
class ObjectTest {
private $container = array();
public function __set($name, $value) {
$this->container[$name] = $value;
}
public function __isset($name) {
return isset($this->container[$name]);
}
public function __unset($name) {
unset($this->container[$name]);
}
public function __get($name) {
return isset($this->container[$name]) ? $this->container[$name]
:
null;
}
}
$array = array();
$array['counter'] = 0;
$array['counter']++;
echo $array['counter'] . "\n";
$objArray = new ArrayTest();
$objArray['counter'] = 0;
$objArray['counter']++;
echo $objArray['counter'] . "\n";
$objAccess = new ObjectTest();
$objAccess->counter = 0;
$objAccess->counter++;
echo $objAccess->counter . "\n";
Expected result:
1
1
1
Actual result:
--
1
0
1
--
Edit this bug report at http://bugs.php.net/bug.php?id=51992&edit=1
[PHP-BUG] Req #51992 [NEW]: ArrayAccess and references
From:
Operating system: Irrelevant
PHP version: Irrelevant
Package: SPL related
Bug Type: Feature/Change Request
Bug description:ArrayAccess and references
Description:
Arrays in PHP contains references to primitive types and reference types.
Which basically means that if you are post-incrementing an element, well,
it actually works.
Why is ArrayAccess::offsetGet() returns by value instead of by reference?
Wasn't ArrayAccess created to emulate an array? This is a major
inconsistency in the platform and makes this whole interface pretty
useless. This isn't an engine limitation. __get(), __set(), __isset(),
__unset() is returning values by reference without any problems. Why can't
ArrayAccess (when it does pretty much the same thing?)
Can ArrayAccess::offsetGet() return by reference (or at the very least
create a second interface, "ArrayAccessRef", for this)?
Test script:
---
container[$name] = $value;
}
public function offsetExists($name) {
return isset($this->container[$name]);
}
public function offsetUnset($name) {
unset($this->container[$name]);
}
public function offsetGet($name) {
return isset($this->container[$name]) ? $this->container[$name]
: null;
}
}
class ObjectTest {
private $container = array();
public function __set($name, $value) {
$this->container[$name] = $value;
}
public function __isset($name) {
return isset($this->container[$name]);
}
public function __unset($name) {
unset($this->container[$name]);
}
public function __get($name) {
return isset($this->container[$name]) ? $this->container[$name]
: null;
}
}
$array = array();
$array['counter'] = 0;
$array['counter']++;
echo $array['counter'] . "\n";
$objArray = new ArrayTest();
$objArray['counter'] = 0;
$objArray['counter']++;
echo $objArray['counter'] . "\n";
$objAccess = new ObjectTest();
$objAccess->counter = 0;
$objAccess->counter++;
echo $objAccess->counter . "\n";
Expected result:
1
1
1
Actual result:
--
1
0
1
--
Edit bug report at http://bugs.php.net/bug.php?id=51992&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51992&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51992&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=51992&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=51992&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51992&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51992&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51992&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51992&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51992&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51992&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51992&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51992&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51992&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51992&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51992&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51992&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51992&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51992&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51992&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51992&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51992&r=mysqlcfg
Bug #51298 [Com]: Error when loading php5apache2_2.dll
Edit report at http://bugs.php.net/bug.php?id=51298&edit=1 ID: 51298 Comment by: sridhar dot devulkar at roost dot com Reported by: trotsky_icepick at hotmail dot com Summary: Error when loading php5apache2_2.dll Status: Assigned Type: Bug Package: Apache2 related Operating System: Windows Vista SP2 PHP Version: 5.3.2 Assigned To: pajoye New Comment: I had the same issue and was resolved by doing the same thing that "peter dot martin at spam dot la" did. All it was needed was to load php5ts.dll and libpq.dll through Apache. Now accessing the php script from the command line as well as from the web page works like a charm. BTW, my setup is this: Operating System: Windows Vista Apache: Apache 2.2.11 PHP: php-5.3.2-Win32-VC6-x86.zip Thanks, Sri. Previous Comments: [2010-05-30 08:49:56] chris dot groothoff at mbits dot com dot au Just to let you know that the suggestion to install the ZIP version (thread safe version) of the installation + manual configuration does allow it to work properly. This would seem to suggest that it seem that the MSI installer version is doing some thing during the install. If I get a chance to pule the MSI apart, it may reveal the what it is trying to do. I have tested version 5.2.3 and 5.2.13, both work fine when installed from the ZIP file. BTW - I have resorted to using 5.2.13 as it contains the PHP_SNMP.DLL that was required to run CACTI as I am not sure where to get a version for 5.2.3. [2010-05-28 00:21:54] paj...@php.net Please, really, stop to add completely unrelated comments to this issue. This bug is clearly identified, there is a thread safe issue with the date initialization. Every recent comments about missing DLLs are not crashes but bad configurations. [2010-05-28 00:19:33] ppylak at gmail dot com Supplement to my previous post. I've added to c:\PHP\ such dlls (from pgAdmin III 1.10 installation): gssapi32.dll, comerr32.dll, krb5_32.dll, libintl-8.dll, libiconv-2.dll, k5sprt32.dll and line Loadfile "C:/PHP/libpq.dll" to httpd.conf and my Apache has started with no changes to php.ini. [2010-05-28 00:01:49] ppylak at gmail dot com In my opinion this problem is connected with loading libpq.dll, which (in present version) needs some other dlls to work, but these dlls aren't included in php MSI installer (and even in zip). [2010-05-27 19:04:33] chris dot groothoff at mbits dot com dot au I have been struggling with te hsame issue on a W2K3 Server SP2. AS soon as you install the PHP 5.3.2 VC9 or V6 version the Apache server fails to start. the event log show the following error - Faulting application httpd.exe, version 2.2.15.0, faulting module php5ts.dll, version 5.3.2.0, fault address 0x000e6d2c. I have also tryied the 5.2.13 VC6 version and this also gives teh same error. I am going to try the ZIP solution suggested, but I can see why people frefer the MSI version :-) I did try to locate an earlier version of Apache V2.0.X, but can not find a binary download. 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/bug.php?id=51298 -- Edit this bug report at http://bugs.php.net/bug.php?id=51298&edit=1
Bug #44454 [Com]: Unexpected exception thrown in foreach() statement
Edit report at http://bugs.php.net/bug.php?id=44454&edit=1
ID: 44454
Comment by: rgagnon24 at gmail dot com
Reported by: mfisc...@php.net
Summary: Unexpected exception thrown in foreach() statement
Status: Verified
Type: Bug
Package: PDO related
Operating System: *
PHP Version: 5.*, 6CVS (2009-04-25)
New Comment:
I've attached a patch "fix-mysql_statement.c-5.2.13.patch" to resolve
this problem.
From: http://dev.mysql.com/doc/refman/5.0/en/mysql-fetch-row.html
"When used after mysql_store_result(), mysql_fetch_row() returns NULL
when there are no more rows to retrieve. When used after
mysql_use_result(), mysql_fetch_row() returns NULL when there are no
more rows to retrieve or if an error occurred"
The patch simply does not raise an exception during a NULL result from
mysql_fetch_row() since it only indicates the exhaustion of data.
The condition added simply matches the use of either mysql_use_result()
or mysql_store_result() called in pdo_mysql_stmt_execute(). When not
buffered, mysql_use_result() is called. Therefore, the same check is
performed after the fetch before deciding to raise an exception.
Also, when un-buffered queries are used, the test script above would be
invalid as you cannot perform another operation on a result-set when not
all of the results have been retrieved.
The patch was created against the released PHP 5.2.3 source code
tarball. It's so small, you should be able to modify it easily for any
version of the mysql_statement.c file.
Previous Comments:
[2010-06-03 20:36:48] rgagnon24 at gmail dot com
From: http://dev.mysql.com/doc/refman/5.0/en/mysql-errno.html
"Note that some functions like mysql_fetch_row() don't set
mysql_errno() if they succeed."
And: http://dev.mysql.com/doc/refman/5.0/en/mysql-fetch-row.html
"Note that error is not reset between calls to mysql_fetch_row()"
-
Since all the SELECT'd rows are fetched ok, the error from the botched
insert is still hanging around for mysql_errno() to find, and raise the
exact same exception after the data is finished being iterated.
[2010-06-03 20:03:37] rgagnon24 at gmail dot com
Looking at pdo_mysql extension source code, I see the exception is
actually being raised twice, not being buffered.
from php5.2.13 source, file ext/pdo_mysql/mysql_statement.c is calling
_pdo_mysql_error() in two places. Once from line 218 in
pdo_mysql_stmt_execute() after mysql_real_query() fails, and then again
at line 425 in pdo_mysql_stmt_fetch() because mysql_errno() indicates
there is an error.
[2010-05-08 06:08:33] gregory at tiv dot net
Correction:
---
if ( $conn->errorCode() ) {
should be
if ( $conn->errorCode() !== '0' ) {
[2010-05-07 02:13:48] gregory at tiv dot net
I have a simpler test case, one solution/explanation and one
workaround.
Tested under:
Windows - PHP 5.2.13 (cli) (built: Feb 24 2010 14:32:32)
FreeBSD - PHP 5.2.12 with Suhosin-Patch 0.9.7 (cli) (built: Feb 24 2010
23:12:45)
Demonstration code:
---
http://www.tiv.net
# 2010-05-06
print 'This code works OK (Exception is cleaned artificially)';
$conn = new PDO( 'mysql:host=localhost', 'test', 'test' );
$conn->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$oRS = $conn->query( "select 'OK'" );
foreach ( $oRS as $row ) {
try {
$conn->query( 'Bogus SQL' );
} catch (PDOException $e) {}
if ( $conn->errorCode() ) {
$conn->query( "select 'CLEAN_PDO_ERROR'" );
}
print 'NO exception will be thrown.';
}
print 'This code works OK (two separate connections)';
$conn = new PDO( 'mysql:host=localhost', 'test', 'test' );
$conn2 = new PDO( 'mysql:host=localhost', 'test', 'test' );
$conn->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$conn2->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$oRS = $conn->query( "select 'OK'" );
foreach ( $oRS as $row ) {
try {
$conn2->query( 'Bogus SQL' );
} catch (PDOException $e) {}
print 'NO exception will be thrown.';
}
print 'This code throws unexpected exception in foreach';
$conn = new PDO( 'mysql:host=localhost', 'test', 'test' );
$conn->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$oRS = $conn->query( "select 'OK'" );
foreach ( $oRS as $row ) {
try {
$conn->query( 'Bogus SQL' );
} catch (PDOException $e) {}
print 'Exception will be thrown after this...';
}
?>
Bug #51266 [Com]: stat failed on cifs-mounted files
Edit report at http://bugs.php.net/bug.php?id=51266&edit=1 ID: 51266 Comment by: dctucker at hotmail dot com Reported by: dctucker at hotmail dot com Summary: stat failed on cifs-mounted files Status: Feedback Type: Bug Package: Filesystem function related Operating System: Arch Linux (current) PHP Version: 5.3.2 New Comment: The mount command lacks noserverino: $ tail -n 1 /etc/fstab //theword/d /mnt/theword cifs nocase,file_mode=0664,dir_mode=0775,username=Administrator%,uid=nobody 0 0 Previous Comments: [2010-05-21 11:23:44] m...@php.net How does the mount command look like, so that it fails? [2010-05-20 21:54:15] dctucker at hotmail dot com Mike, Using the 'noserverino' workaround does mitigate the problem, but it does not address the underlying issue. [2010-05-20 12:19:16] m...@php.net Works fine here too, so I assume it's not a PHP bug. [2010-03-24 20:05:42] mail at daniel-berlin dot de Adding cifs option "noserverino" solves the problem. [2010-03-23 19:23:33] mail at daniel-berlin dot de Sorry, I meant 5.2.4 ... 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/bug.php?id=51266 -- Edit this bug report at http://bugs.php.net/bug.php?id=51266&edit=1
Bug #44454 [Com]: Unexpected exception thrown in foreach() statement
Edit report at http://bugs.php.net/bug.php?id=44454&edit=1
ID: 44454
Comment by: rgagnon24 at gmail dot com
Reported by: mfisc...@php.net
Summary: Unexpected exception thrown in foreach() statement
Status: Verified
Type: Bug
Package: PDO related
Operating System: *
PHP Version: 5.*, 6CVS (2009-04-25)
New Comment:
From: http://dev.mysql.com/doc/refman/5.0/en/mysql-errno.html
"Note that some functions like mysql_fetch_row() don't set
mysql_errno() if they succeed."
And: http://dev.mysql.com/doc/refman/5.0/en/mysql-fetch-row.html
"Note that error is not reset between calls to mysql_fetch_row()"
-
Since all the SELECT'd rows are fetched ok, the error from the botched
insert is still hanging around for mysql_errno() to find, and raise the
exact same exception after the data is finished being iterated.
Previous Comments:
[2010-06-03 20:03:37] rgagnon24 at gmail dot com
Looking at pdo_mysql extension source code, I see the exception is
actually being raised twice, not being buffered.
from php5.2.13 source, file ext/pdo_mysql/mysql_statement.c is calling
_pdo_mysql_error() in two places. Once from line 218 in
pdo_mysql_stmt_execute() after mysql_real_query() fails, and then again
at line 425 in pdo_mysql_stmt_fetch() because mysql_errno() indicates
there is an error.
[2010-05-08 06:08:33] gregory at tiv dot net
Correction:
---
if ( $conn->errorCode() ) {
should be
if ( $conn->errorCode() !== '0' ) {
[2010-05-07 02:13:48] gregory at tiv dot net
I have a simpler test case, one solution/explanation and one
workaround.
Tested under:
Windows - PHP 5.2.13 (cli) (built: Feb 24 2010 14:32:32)
FreeBSD - PHP 5.2.12 with Suhosin-Patch 0.9.7 (cli) (built: Feb 24 2010
23:12:45)
Demonstration code:
---
http://www.tiv.net
# 2010-05-06
print 'This code works OK (Exception is cleaned artificially)';
$conn = new PDO( 'mysql:host=localhost', 'test', 'test' );
$conn->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$oRS = $conn->query( "select 'OK'" );
foreach ( $oRS as $row ) {
try {
$conn->query( 'Bogus SQL' );
} catch (PDOException $e) {}
if ( $conn->errorCode() ) {
$conn->query( "select 'CLEAN_PDO_ERROR'" );
}
print 'NO exception will be thrown.';
}
print 'This code works OK (two separate connections)';
$conn = new PDO( 'mysql:host=localhost', 'test', 'test' );
$conn2 = new PDO( 'mysql:host=localhost', 'test', 'test' );
$conn->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$conn2->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$oRS = $conn->query( "select 'OK'" );
foreach ( $oRS as $row ) {
try {
$conn2->query( 'Bogus SQL' );
} catch (PDOException $e) {}
print 'NO exception will be thrown.';
}
print 'This code throws unexpected exception in foreach';
$conn = new PDO( 'mysql:host=localhost', 'test', 'test' );
$conn->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$oRS = $conn->query( "select 'OK'" );
foreach ( $oRS as $row ) {
try {
$conn->query( 'Bogus SQL' );
} catch (PDOException $e) {}
print 'Exception will be thrown after this...';
}
?>
[2009-04-25 17:16:14] mfisc...@php.net
Using Windows snapshots, verified that the bug still exists in
5.2.10-dev and 5.3.0RC2-dev . Cannot test with 6.0.0-dev, the php.exe
doesn't even properly start.
[2009-04-25 14:57:23] j...@php.net
Does this still exist? If so, update the version properly.. ;)
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/bug.php?id=44454
--
Edit this bug report at http://bugs.php.net/bug.php?id=44454&edit=1
Bug #44454 [Com]: Unexpected exception thrown in foreach() statement
Edit report at http://bugs.php.net/bug.php?id=44454&edit=1
ID: 44454
Comment by: rgagnon24 at gmail dot com
Reported by: mfisc...@php.net
Summary: Unexpected exception thrown in foreach() statement
Status: Verified
Type: Bug
Package: PDO related
Operating System: *
PHP Version: 5.*, 6CVS (2009-04-25)
New Comment:
Looking at pdo_mysql extension source code, I see the exception is
actually being raised twice, not being buffered.
from php5.2.13 source, file ext/pdo_mysql/mysql_statement.c is calling
_pdo_mysql_error() in two places. Once from line 218 in
pdo_mysql_stmt_execute() after mysql_real_query() fails, and then again
at line 425 in pdo_mysql_stmt_fetch() because mysql_errno() indicates
there is an error.
Previous Comments:
[2010-05-08 06:08:33] gregory at tiv dot net
Correction:
---
if ( $conn->errorCode() ) {
should be
if ( $conn->errorCode() !== '0' ) {
[2010-05-07 02:13:48] gregory at tiv dot net
I have a simpler test case, one solution/explanation and one
workaround.
Tested under:
Windows - PHP 5.2.13 (cli) (built: Feb 24 2010 14:32:32)
FreeBSD - PHP 5.2.12 with Suhosin-Patch 0.9.7 (cli) (built: Feb 24 2010
23:12:45)
Demonstration code:
---
http://www.tiv.net
# 2010-05-06
print 'This code works OK (Exception is cleaned artificially)';
$conn = new PDO( 'mysql:host=localhost', 'test', 'test' );
$conn->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$oRS = $conn->query( "select 'OK'" );
foreach ( $oRS as $row ) {
try {
$conn->query( 'Bogus SQL' );
} catch (PDOException $e) {}
if ( $conn->errorCode() ) {
$conn->query( "select 'CLEAN_PDO_ERROR'" );
}
print 'NO exception will be thrown.';
}
print 'This code works OK (two separate connections)';
$conn = new PDO( 'mysql:host=localhost', 'test', 'test' );
$conn2 = new PDO( 'mysql:host=localhost', 'test', 'test' );
$conn->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$conn2->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$oRS = $conn->query( "select 'OK'" );
foreach ( $oRS as $row ) {
try {
$conn2->query( 'Bogus SQL' );
} catch (PDOException $e) {}
print 'NO exception will be thrown.';
}
print 'This code throws unexpected exception in foreach';
$conn = new PDO( 'mysql:host=localhost', 'test', 'test' );
$conn->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$oRS = $conn->query( "select 'OK'" );
foreach ( $oRS as $row ) {
try {
$conn->query( 'Bogus SQL' );
} catch (PDOException $e) {}
print 'Exception will be thrown after this...';
}
?>
[2009-04-25 17:16:14] mfisc...@php.net
Using Windows snapshots, verified that the bug still exists in
5.2.10-dev and 5.3.0RC2-dev . Cannot test with 6.0.0-dev, the php.exe
doesn't even properly start.
[2009-04-25 14:57:23] j...@php.net
Does this still exist? If so, update the version properly.. ;)
[2008-07-03 16:44:39] u...@php.net
Correction:
emulated prepared statements - not using traversable - Issue exists
emulated prepared statement - using traversable - Issue exists
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/bug.php?id=44454
--
Edit this bug report at http://bugs.php.net/bug.php?id=44454&edit=1
Bug #51946 [Fbk->Opn]: Segmentation Faults on postgres use in session handler.
Edit report at http://bugs.php.net/bug.php?id=51946&edit=1
ID: 51946
User updated by: justin_burger at adp dot com
Reported by: justin_burger at adp dot com
-Summary: Segmentation Faults on postgres function use.
+Summary: Segmentation Faults on postgres use in session
handler.
-Status: Feedback
+Status: Open
Type: Bug
Package: PostgreSQL related
Operating System: CentOS release 5.4 (Final)
PHP Version: 5.2.13
New Comment:
This now seems isolated to the session handler use of postgres.
Previous Comments:
[2010-06-03 19:49:09] justin_burger at adp dot com
I've done more research and confirmed that I can ONLY reproduce this
when using
postgres as part of session management. executing the exact same SQL
outside of a
session handler does not cause the fault.
[2010-06-02 23:22:56] justin_burger at adp dot com
PG Version =8.3.9
Your right, it looks like it's not happening 100% of the time during the
pg_connect. I created a somewhat simple script which causes the fault on
every other request. I am able to reproduce this on two different
servers. both running 5.2.13 with the 8.3.9 version of postgres.
Code to reproduce: http://pastebin.com/nfNJeyMw
Running this script gives me the following backtrace:
Core was generated by `/opt/adp/httpd/bin/httpd -X'.
Program terminated with signal 11, Segmentation fault.
#0 0x2ac7d6ee1c20 in zend_mm_search_large_block (heap=0x151bdd50,
size=24) at /usr/src/debug/php-5.2.13/Zend/zend_alloc.c:1753
1753if (ZEND_MM_FREE_BLOCK_SIZE(p) <
ZEND_MM_FREE_BLOCK_SIZE(best_fit)) {
(gdb) bt
#0 0x2ac7d6ee1c20 in zend_mm_search_large_block (heap=0x151bdd50,
size=24) at /usr/src/debug/php-5.2.13/Zend/zend_alloc.c:1753
#1 _zend_mm_alloc_int (heap=0x151bdd50, size=24) at
/usr/src/debug/php-5.2.13/Zend/zend_alloc.c:1812
#2 0x2ac7dcdd8e80 in zif_pg_query (ht=,
return_value=0x15671350, return_value_ptr=,
this_ptr=, return_value_used=) at /usr/src/debug/php-5.2.13/ext/pgsql/pgsql.c:1184
#3 0x2ac7d6f1d582 in zend_do_fcall_common_helper_SPEC
(execute_data=0x7fff68c97af0) at
/usr/src/debug/php-5.2.13/Zend/zend_vm_execute.h:200
#4 0x2ac7d6f1c73c in execute (op_array=0x155df890) at
/usr/src/debug/php-5.2.13/Zend/zend_vm_execute.h:92
#5 0x2ac7d6ef1299 in zend_call_function (fci=0x7fff68c97cd0,
fci_cache=) at
/usr/src/debug/php-5.2.13/Zend/zend_execute_API.c:1039
#6 0x2ac7d6ef2386 in call_user_function_ex (function_table=, object_pp=,
function_name=0x7274732061206e69,
retval_ptr_ptr=0x1541dda0, param_count=1, params=0x0,
no_separation=1, symbol_table=0x0) at
/usr/src/debug/php-5.2.13/Zend/zend_execute_API.c:640
#7 0x2ac7d6ef2406 in call_user_function (function_table=0x151bd640,
object_pp=0x0, function_name=0x15421298, retval_ptr=0x15642688,
param_count=2,
params=0x7fff68c97dc0) at
/usr/src/debug/php-5.2.13/Zend/zend_execute_API.c:613
#8 0x2ac7d6da5e25 in ps_call_handler (func=0x15421298, argc=2,
argv=0x7fff68c97dc0) at
/usr/src/debug/php-5.2.13/ext/session/mod_user.c:53
#9 0x2ac7d6da6099 in ps_write_user (mod_data=,
key=0x1560c698 "6c4u9vvv7b2hb5jh1bgg3916m6",
val=0x156700a8
"CONNECTION_ID|s:2:\"QA\";USER_OBJECT|s:3667:\"O:4:\"user\":22:{s:17:\"",
vallen=3712)
at /usr/src/debug/php-5.2.13/ext/session/mod_user.c:141
#10 0x2ac7d6da2022 in php_session_save_current_state () at
/usr/src/debug/php-5.2.13/ext/session/session.c:550
#11 php_session_flush () at
/usr/src/debug/php-5.2.13/ext/session/session.c:1407
#12 0x2ac7d6da22e9 in zm_deactivate_session (type=354147664,
module_number=5) at
/usr/src/debug/php-5.2.13/ext/session/session.c:2015
#13 0x2ac7d6efddfc in module_registry_cleanup (module=) at /usr/src/debug/php-5.2.13/Zend/zend_API.c:1976
#14 0x2ac7d6f06d84 in zend_hash_reverse_apply (ht=0x2ac7d74abb00,
apply_func=0x2ac7d6efdde0 )
at /usr/src/debug/php-5.2.13/Zend/zend_hash.c:755
#15 0x2ac7d6efc47d in zend_deactivate_modules () at
/usr/src/debug/php-5.2.13/Zend/zend.c:838
#16 0x2ac7d6eb944a in php_request_shutdown (dummy=) at /usr/src/debug/php-5.2.13/main/main.c:1478
#17 0x2ac7d6f80b9e in php_apache_request_dtor (r=0x15458be0) at
/usr/src/debug/php-5.2.13/sapi/apache2handler/sapi_apache2.c:479
#18 php_handler (r=0x15458be0) at
/usr/src/debug/php-5.2.13/sapi/apache2handler/sapi_apache2.c:651
#19 0x004362ea in ap_run_handler (r=0x15458be0) at config.c:157
#20 0x0043952c in ap_invoke_handler (r=0x15458be0) at
config.c:372
#21 0x00443b58 in ap_process_request (r=0x15458be0) at
http_request.c:282
#22 0x00440efc in ap_process_http_connection (c=0x1544ed80) at
http_core.c:190
#23 0x0043d202 in ap_run_process_connection (c=0x1544ed80) at
con
Bug #51946 [Com]: Segmentation Faults on postgres function use.
Edit report at http://bugs.php.net/bug.php?id=51946&edit=1
ID: 51946
Comment by: justin_burger at adp dot com
Reported by: justin_burger at adp dot com
Summary: Segmentation Faults on postgres function use.
Status: Feedback
Type: Bug
Package: PostgreSQL related
Operating System: CentOS release 5.4 (Final)
PHP Version: 5.2.13
New Comment:
I've done more research and confirmed that I can ONLY reproduce this
when using
postgres as part of session management. executing the exact same SQL
outside of a
session handler does not cause the fault.
Previous Comments:
[2010-06-02 23:22:56] justin_burger at adp dot com
PG Version =8.3.9
Your right, it looks like it's not happening 100% of the time during the
pg_connect. I created a somewhat simple script which causes the fault on
every other request. I am able to reproduce this on two different
servers. both running 5.2.13 with the 8.3.9 version of postgres.
Code to reproduce: http://pastebin.com/nfNJeyMw
Running this script gives me the following backtrace:
Core was generated by `/opt/adp/httpd/bin/httpd -X'.
Program terminated with signal 11, Segmentation fault.
#0 0x2ac7d6ee1c20 in zend_mm_search_large_block (heap=0x151bdd50,
size=24) at /usr/src/debug/php-5.2.13/Zend/zend_alloc.c:1753
1753if (ZEND_MM_FREE_BLOCK_SIZE(p) <
ZEND_MM_FREE_BLOCK_SIZE(best_fit)) {
(gdb) bt
#0 0x2ac7d6ee1c20 in zend_mm_search_large_block (heap=0x151bdd50,
size=24) at /usr/src/debug/php-5.2.13/Zend/zend_alloc.c:1753
#1 _zend_mm_alloc_int (heap=0x151bdd50, size=24) at
/usr/src/debug/php-5.2.13/Zend/zend_alloc.c:1812
#2 0x2ac7dcdd8e80 in zif_pg_query (ht=,
return_value=0x15671350, return_value_ptr=,
this_ptr=, return_value_used=) at /usr/src/debug/php-5.2.13/ext/pgsql/pgsql.c:1184
#3 0x2ac7d6f1d582 in zend_do_fcall_common_helper_SPEC
(execute_data=0x7fff68c97af0) at
/usr/src/debug/php-5.2.13/Zend/zend_vm_execute.h:200
#4 0x2ac7d6f1c73c in execute (op_array=0x155df890) at
/usr/src/debug/php-5.2.13/Zend/zend_vm_execute.h:92
#5 0x2ac7d6ef1299 in zend_call_function (fci=0x7fff68c97cd0,
fci_cache=) at
/usr/src/debug/php-5.2.13/Zend/zend_execute_API.c:1039
#6 0x2ac7d6ef2386 in call_user_function_ex (function_table=, object_pp=,
function_name=0x7274732061206e69,
retval_ptr_ptr=0x1541dda0, param_count=1, params=0x0,
no_separation=1, symbol_table=0x0) at
/usr/src/debug/php-5.2.13/Zend/zend_execute_API.c:640
#7 0x2ac7d6ef2406 in call_user_function (function_table=0x151bd640,
object_pp=0x0, function_name=0x15421298, retval_ptr=0x15642688,
param_count=2,
params=0x7fff68c97dc0) at
/usr/src/debug/php-5.2.13/Zend/zend_execute_API.c:613
#8 0x2ac7d6da5e25 in ps_call_handler (func=0x15421298, argc=2,
argv=0x7fff68c97dc0) at
/usr/src/debug/php-5.2.13/ext/session/mod_user.c:53
#9 0x2ac7d6da6099 in ps_write_user (mod_data=,
key=0x1560c698 "6c4u9vvv7b2hb5jh1bgg3916m6",
val=0x156700a8
"CONNECTION_ID|s:2:\"QA\";USER_OBJECT|s:3667:\"O:4:\"user\":22:{s:17:\"",
vallen=3712)
at /usr/src/debug/php-5.2.13/ext/session/mod_user.c:141
#10 0x2ac7d6da2022 in php_session_save_current_state () at
/usr/src/debug/php-5.2.13/ext/session/session.c:550
#11 php_session_flush () at
/usr/src/debug/php-5.2.13/ext/session/session.c:1407
#12 0x2ac7d6da22e9 in zm_deactivate_session (type=354147664,
module_number=5) at
/usr/src/debug/php-5.2.13/ext/session/session.c:2015
#13 0x2ac7d6efddfc in module_registry_cleanup (module=) at /usr/src/debug/php-5.2.13/Zend/zend_API.c:1976
#14 0x2ac7d6f06d84 in zend_hash_reverse_apply (ht=0x2ac7d74abb00,
apply_func=0x2ac7d6efdde0 )
at /usr/src/debug/php-5.2.13/Zend/zend_hash.c:755
#15 0x2ac7d6efc47d in zend_deactivate_modules () at
/usr/src/debug/php-5.2.13/Zend/zend.c:838
#16 0x2ac7d6eb944a in php_request_shutdown (dummy=) at /usr/src/debug/php-5.2.13/main/main.c:1478
#17 0x2ac7d6f80b9e in php_apache_request_dtor (r=0x15458be0) at
/usr/src/debug/php-5.2.13/sapi/apache2handler/sapi_apache2.c:479
#18 php_handler (r=0x15458be0) at
/usr/src/debug/php-5.2.13/sapi/apache2handler/sapi_apache2.c:651
#19 0x004362ea in ap_run_handler (r=0x15458be0) at config.c:157
#20 0x0043952c in ap_invoke_handler (r=0x15458be0) at
config.c:372
#21 0x00443b58 in ap_process_request (r=0x15458be0) at
http_request.c:282
#22 0x00440efc in ap_process_http_connection (c=0x1544ed80) at
http_core.c:190
#23 0x0043d202 in ap_run_process_connection (c=0x1544ed80) at
connection.c:43
#24 0x00447a90 in child_main (child_num_arg=) at prefork.c:662
#25 0x00447c93 in make_child (s=0x1509b848, slot=0) at
prefork.c:702
#26 0x00448866 in ap_mpm_run (_pconf=,
plog=, s=0x1509b848) at prefork.c:978
#27 0x00423e98 in main (argc=2, argv=0x7fff68c98848
[PHP-BUG] Bug #51991 [NEW]: spl_autoload and *nix support with namespace
From:
Operating system: linux, mac, *nix
PHP version: 5.3.2
Package: SPL related
Bug Type: Bug
Bug description:spl_autoload and *nix support with namespace
Description:
On windows systems you can use spl_autload to load namespaced class and it
works!
On *nix system you can't!
Tested on linux (ubuntu 10.04 64 bit) with package : php5 5.3.2-1ubuntu4.2
You can test the next script on a windows and on a linux or a mac.
Test script:
---
create a file called index.php
--
use My\Framework\Test;
spl_autoload_register();
$test = new Test();
echo $test;
--
Another file in a subdir My/Framework called Test.php
--
namespace My\Framework;
class Test
{
public function __toString()
{
return 'hi';
}
}
--
Expected result:
Expected result :
script that produce :
hi
Actual result:
--
windows:
hi
Linux:
Fatal error: spl_autoload() [function.spl-autoload]: Class
My\Framework\Test could not be loaded in /.../index.php on line 7
--
Edit bug report at http://bugs.php.net/bug.php?id=51991&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51991&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51991&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=51991&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=51991&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51991&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51991&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51991&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51991&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51991&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51991&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51991&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51991&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51991&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51991&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51991&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51991&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51991&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51991&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51991&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51991&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51991&r=mysqlcfg
Bug #51863 [Com]: date format
Edit report at http://bugs.php.net/bug.php?id=51863&edit=1
ID: 51863
Comment by: rgagnon24 at gmail dot com
Reported by: corey dot barnes at verizon dot com
Summary: date format
Status: Open
Type: Bug
Package: PDO related
Operating System: RHEL 5 - linux
PHP Version: 5.1.6
New Comment:
Another thing I just thought about. If the date format were to be
changed now, it would break compatibility with existing PHP code.
Previous Comments:
[2010-06-03 17:56:47] rgagnon24 at gmail dot com
This could be to keep the date format standard among all PDO drivers, so
code does not need to be aware of the database storage types.
Also, pdo_informix is a PECL extension. Should this be an issue for
PECL?
[2010-05-20 15:17:54] corey dot barnes at verizon dot com
This is not dependent on a server setting. I can query using IFX
functions (for INFORMIX) and the date is returned in the correct format,
but when I use the PDO functions it returns as -mm-dd (instead of
mm/dd/).
[2010-05-20 14:10:35] m...@php.net
Hi, is this by any chance dependent on your locale, or on a date output
format setting of the server?
[2010-05-19 22:52:45] corey dot barnes at verizon dot com
Description:
When using the PDO connection option to an Informix data base the date
is returned in the format -MM-DD instead of in the format that it is
stored in the database.
Test script:
---
try {
$pdo=new PDO('informix:host=$host; database=$db; server=$server;
protocol=onsoctcp;',"","",array(PDO::ATTR_PERSISTENT=>true));
} catch (PDOexception $e) {
echo "Failed to get DB handle: " . $e->getMessage() . "\n";
exit;
}
$sql = "SELECT dba_date,due_date FROM work_requests Where
work_id='6862105'";
$q = $pdo->prepare($sql);
$q->execute();
$q->setFetchMode(PDO::FETCH_BOTH);
while($sqlr = $q->fetch()){
print $sqlr['DBA_DATE'] ."";
print $sqlr['DUE_DATE'] ."";
}
Expected result:
mm/dd/
Actual result:
--
-mm-dd
--
Edit this bug report at http://bugs.php.net/bug.php?id=51863&edit=1
Bug #51863 [Com]: date format
Edit report at http://bugs.php.net/bug.php?id=51863&edit=1
ID: 51863
Comment by: rgagnon24 at gmail dot com
Reported by: corey dot barnes at verizon dot com
Summary: date format
Status: Open
Type: Bug
Package: PDO related
Operating System: RHEL 5 - linux
PHP Version: 5.1.6
New Comment:
This could be to keep the date format standard among all PDO drivers, so
code does not need to be aware of the database storage types.
Also, pdo_informix is a PECL extension. Should this be an issue for
PECL?
Previous Comments:
[2010-05-20 15:17:54] corey dot barnes at verizon dot com
This is not dependent on a server setting. I can query using IFX
functions (for INFORMIX) and the date is returned in the correct format,
but when I use the PDO functions it returns as -mm-dd (instead of
mm/dd/).
[2010-05-20 14:10:35] m...@php.net
Hi, is this by any chance dependent on your locale, or on a date output
format setting of the server?
[2010-05-19 22:52:45] corey dot barnes at verizon dot com
Description:
When using the PDO connection option to an Informix data base the date
is returned in the format -MM-DD instead of in the format that it is
stored in the database.
Test script:
---
try {
$pdo=new PDO('informix:host=$host; database=$db; server=$server;
protocol=onsoctcp;',"","",array(PDO::ATTR_PERSISTENT=>true));
} catch (PDOexception $e) {
echo "Failed to get DB handle: " . $e->getMessage() . "\n";
exit;
}
$sql = "SELECT dba_date,due_date FROM work_requests Where
work_id='6862105'";
$q = $pdo->prepare($sql);
$q->execute();
$q->setFetchMode(PDO::FETCH_BOTH);
while($sqlr = $q->fetch()){
print $sqlr['DBA_DATE'] ."";
print $sqlr['DUE_DATE'] ."";
}
Expected result:
mm/dd/
Actual result:
--
-mm-dd
--
Edit this bug report at http://bugs.php.net/bug.php?id=51863&edit=1
Req #51987 [Opn]: Datetime fails to parse an ISO 8601 ordinal date (extended format)
Edit report at http://bugs.php.net/bug.php?id=51987&edit=1
ID: 51987
Updated by: sala...@php.net
Reported by: jbondc at openmv dot com
Summary: Datetime fails to parse an ISO 8601 ordinal date
(extended format)
Status: Open
Type: Feature/Change Request
Package: Date/time related
Operating System: FreeBSD
PHP Version: 5.2.13
New Comment:
Forgive my initial hastiness, I overlooked the fact that doy should
always be 3-
digits in length. Sorry!!
Previous Comments:
[2010-06-03 15:04:19] der...@php.net
It's a feature request though, *but* before we add it we must be certain
that it doesn't conflict.
[2010-06-03 14:55:14] jbondc at openmv dot com
Please leave this bug open, I will look at submitting a patch.
There is no reason not to support:
$d2 = new Datetime('1985-001');
$d2 = new Datetime('1985-002');
...
$d2 = new Datetime('1985-365');
AND
$d2 = new Datetime('1985-01');
$d2 = new Datetime('1985-12');
[2010-06-03 14:36:21] sala...@php.net
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
Currently only YYdoy and YY.doy are supported. Adding in YY-doy would
conflict
with existing support for YY-mm. See http://php.net/datetime.formats for
details
of what is currently available.
(Key: YY = four-digit year, doy = day of year, mm = month number.)
[2010-06-03 13:55:51] jbondc at openmv dot com
Description:
PHP 5.2.12 with Suhosin-Patch 0.9.7 (cli) (built: Dec 30 2009 15:41:26)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies
with Zend Optimizer v3.3.9, Copyright (c) 1998-2009, by Zend
Technologies
Test script:
---
// Ordinal date â 12 April 1985
$d1 = new Datetime('1985102');
// OK
$d2 = new Datetime('1985-102');
// Exception: DateTime::__construct(): Failed to parse time string
(1985-102) at position 7 (2): Unexpected character
--
Edit this bug report at http://bugs.php.net/bug.php?id=51987&edit=1
Bug->Req #51987 [Bgs->Opn]: Datetime fails to parse an ISO 8601 ordinal date (extended format)
Edit report at http://bugs.php.net/bug.php?id=51987&edit=1
ID: 51987
Updated by: der...@php.net
Reported by: jbondc at openmv dot com
Summary: Datetime fails to parse an ISO 8601 ordinal date
(extended format)
-Status: Bogus
+Status: Open
-Type: Bug
+Type: Feature/Change Request
Package: Date/time related
Operating System: FreeBSD
PHP Version: 5.2.13
New Comment:
It's a feature request though, *but* before we add it we must be certain
that it doesn't conflict.
Previous Comments:
[2010-06-03 14:55:14] jbondc at openmv dot com
Please leave this bug open, I will look at submitting a patch.
There is no reason not to support:
$d2 = new Datetime('1985-001');
$d2 = new Datetime('1985-002');
...
$d2 = new Datetime('1985-365');
AND
$d2 = new Datetime('1985-01');
$d2 = new Datetime('1985-12');
[2010-06-03 14:36:21] sala...@php.net
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
Currently only YYdoy and YY.doy are supported. Adding in YY-doy would
conflict
with existing support for YY-mm. See http://php.net/datetime.formats for
details
of what is currently available.
(Key: YY = four-digit year, doy = day of year, mm = month number.)
[2010-06-03 13:55:51] jbondc at openmv dot com
Description:
PHP 5.2.12 with Suhosin-Patch 0.9.7 (cli) (built: Dec 30 2009 15:41:26)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies
with Zend Optimizer v3.3.9, Copyright (c) 1998-2009, by Zend
Technologies
Test script:
---
// Ordinal date â 12 April 1985
$d1 = new Datetime('1985102');
// OK
$d2 = new Datetime('1985-102');
// Exception: DateTime::__construct(): Failed to parse time string
(1985-102) at position 7 (2): Unexpected character
--
Edit this bug report at http://bugs.php.net/bug.php?id=51987&edit=1
Bug #51987 [Bgs]: Datetime fails to parse an ISO 8601 ordinal date (extended format)
Edit report at http://bugs.php.net/bug.php?id=51987&edit=1
ID: 51987
User updated by: jbondc at openmv dot com
Reported by: jbondc at openmv dot com
Summary: Datetime fails to parse an ISO 8601 ordinal date
(extended format)
Status: Bogus
Type: Bug
Package: Date/time related
Operating System: FreeBSD
PHP Version: 5.2.13
New Comment:
Please leave this bug open, I will look at submitting a patch.
There is no reason not to support:
$d2 = new Datetime('1985-001');
$d2 = new Datetime('1985-002');
...
$d2 = new Datetime('1985-365');
AND
$d2 = new Datetime('1985-01');
$d2 = new Datetime('1985-12');
Previous Comments:
[2010-06-03 14:36:21] sala...@php.net
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
Currently only YYdoy and YY.doy are supported. Adding in YY-doy would
conflict
with existing support for YY-mm. See http://php.net/datetime.formats for
details
of what is currently available.
(Key: YY = four-digit year, doy = day of year, mm = month number.)
[2010-06-03 13:55:51] jbondc at openmv dot com
Description:
PHP 5.2.12 with Suhosin-Patch 0.9.7 (cli) (built: Dec 30 2009 15:41:26)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies
with Zend Optimizer v3.3.9, Copyright (c) 1998-2009, by Zend
Technologies
Test script:
---
// Ordinal date â 12 April 1985
$d1 = new Datetime('1985102');
// OK
$d2 = new Datetime('1985-102');
// Exception: DateTime::__construct(): Failed to parse time string
(1985-102) at position 7 (2): Unexpected character
--
Edit this bug report at http://bugs.php.net/bug.php?id=51987&edit=1
[PHP-BUG] Bug #51989 [NEW]: PDO class doesn't connect but reuse open connections
From: Operating system: Windows PHP version: 5.3.2 Package: *Database Functions Bug Type: Bug Bug description:PDO class doesn't connect but reuse open connections Description: The manual says that the PDO class represents a database connection. Thus I assume that when I instantiate two PDO classes, I get two database connections. But instead, when using the same connection data, I do not get a second connection but the first connection is simply reused. I need a separate connection for logging purposes, it cannot use the primary connection that's affected by transactions and all such things. I do get a separate connection when I connect to "127.0.0.1" instead of "localhost", which is a different string but the same meaning. This is a hack though because there are very limited alternatives to define the same host. Expected result: I expect every PDO instance to actually give me a new connection, at least when another connection is already in use. Actual result: -- It gives me the old connection that is used for transactions and such. My programme doesn't work then. It needs another connection. -- Edit bug report at http://bugs.php.net/bug.php?id=51989&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51989&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51989&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=51989&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=51989&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51989&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51989&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51989&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51989&r=needscript Try newer version: http://bugs.php.net/fix.php?id=51989&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51989&r=support Expected behavior: http://bugs.php.net/fix.php?id=51989&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51989&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51989&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51989&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51989&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51989&r=dst IIS Stability: http://bugs.php.net/fix.php?id=51989&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51989&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51989&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51989&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51989&r=mysqlcfg
Bug #51987 [Opn->Bgs]: Datetime fails to parse an ISO 8601 ordinal date (extended format)
Edit report at http://bugs.php.net/bug.php?id=51987&edit=1
ID: 51987
Updated by: sala...@php.net
Reported by: jbondc at openmv dot com
Summary: Datetime fails to parse an ISO 8601 ordinal date
(extended format)
-Status: Open
+Status: Bogus
Type: Bug
Package: Date/time related
Operating System: FreeBSD
PHP Version: 5.2.13
New Comment:
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
Currently only YYdoy and YY.doy are supported. Adding in YY-doy would
conflict
with existing support for YY-mm. See http://php.net/datetime.formats for
details
of what is currently available.
(Key: YY = four-digit year, doy = day of year, mm = month number.)
Previous Comments:
[2010-06-03 13:55:51] jbondc at openmv dot com
Description:
PHP 5.2.12 with Suhosin-Patch 0.9.7 (cli) (built: Dec 30 2009 15:41:26)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies
with Zend Optimizer v3.3.9, Copyright (c) 1998-2009, by Zend
Technologies
Test script:
---
// Ordinal date â 12 April 1985
$d1 = new Datetime('1985102');
// OK
$d2 = new Datetime('1985-102');
// Exception: DateTime::__construct(): Failed to parse time string
(1985-102) at position 7 (2): Unexpected character
--
Edit this bug report at http://bugs.php.net/bug.php?id=51987&edit=1
Bug #51986 [Opn]: array_filter breaks references when a callback is used
Edit report at http://bugs.php.net/bug.php?id=51986&edit=1
ID: 51986
User updated by: daniel dot menard at ehesp dot fr
Reported by: daniel dot menard at ehesp dot fr
Summary: array_filter breaks references when a callback is used
Status: Open
Type: Bug
Package: Arrays related
Operating System: Windows XP
PHP Version: 5.3.2
New Comment:
Thanks for your comment: your workaround works.
However, having to redefine standard php functions like trim() or
count() just to be able to use them with array_filter() is not very
convenient, is it?
The fact is that the function behaviour changed in a "revision release"
which should not have broken my code...
;-)
Previous Comments:
[2010-06-03 13:00:43] sjo...@php.net
Use a reference in your callback function:
function my_trim(& $a)
{
return trim($a);
}
[2010-06-03 12:28:24] daniel dot menard at ehesp dot fr
Description:
I have an array and a variable which is a reference on some element in
this array:
$arr=array('a'); $ref = &$arr[0]
If I apply array_filter() with a callback like trim() or count() on the
array, the reference is broken and $ref is no longer a reference (If I
apply array_filter() without a callback, the reference is not altered
and the result is correct).
I think that this is a regression introduced in php 5.2.11: with the
test script below, 5.2.10 give the good result, 5.2.11 do not.
I also tested with the latest version (5.3.2): same result, reference is
broken.
PS: I tested on windows XP with packages php-5.x.y-Win32-VC6-x86.zip
provided on this page:
http://windows.php.net/downloads/releases/archives/
Test script:
---
// Init
$arr = array('some value');
$ref = & $arr[0];
// Change $arr
$arr[0] = 'ONE';
echo 'step 1. $ref is ', ($ref !== 'ONE') ? 'BROKEN' : 'OK', "\n";
// Apply array_filter (without callback) and change $arr
array_filter($arr);
$arr[0] = 'TWO';
echo 'step 2. $ref is ', ($ref !== 'TWO') ? 'BROKEN' : 'OK', "\n";
// Apply array_filter (with a callback) then change $arr
array_filter($arr,'trim');
$arr[0] = 'THREE';
echo 'step 3. $ref is ', ($ref !== 'THREE') ? 'BROKEN' : 'OK', "\n";
Expected result:
step 1. $ref is OK
step 2. $ref is OK
step 3. $ref is OK
Actual result:
--
step 1. $ref is OK
step 2. $ref is OK
step 3. $ref is BROKEN
--
Edit this bug report at http://bugs.php.net/bug.php?id=51986&edit=1
[PHP-BUG] Bug #51988 [NEW]: No input file specfied when trying to exec any PHP script from Web Server
From:
Operating system: SunOS 5.8 sparc
PHP version: 5.2.13
Package: CGI related
Bug Type: Bug
Bug description:No input file specfied when trying to exec any PHP script from
Web Server
Description:
When trying to run any PHP script from my Web Server (Sun Java System Web
Server 6.1) as CGI always get "No input file specified".
Configure options:
./configure --with-curl --with-mysql=/usr/local/mysql
--prefix=/usr/local/php5 --with-config-file-path=/usr/local/php5/lib
-enable-force-cgi-redirect
Changed PUTS("No input file specifiedd.\n"); by
PUTS(zend_printf("%s",file_handle.filename)); at line 1947 in cgi_main.c
and what i can see at the browser is (null) so the problem is with
path_translated for sure.
I've a lot of PHPP4.1 scripts running at the same Web server so the
configurantion is the same. It is not too probalbe that the problem is at
the Web Server.
Thanks a lot.
Test script:
---
matrix /data/web_html/publicado/empresafamiliar/php5 425 #more
phpinfo5.php
#!/usr/local/bin/php5
Expected result:
I expect an HTML page with the result of the phpinfo function.
Actual result:
--
No input file specified
--
Edit bug report at http://bugs.php.net/bug.php?id=51988&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51988&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51988&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=51988&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=51988&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51988&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51988&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51988&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51988&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51988&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51988&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51988&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51988&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51988&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51988&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51988&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51988&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51988&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51988&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51988&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51988&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51988&r=mysqlcfg
[PHP-BUG] Bug #51987 [NEW]: Datetime fails to parse an ISO 8601 ordinal date (extended format)
From:
Operating system: FreeBSD
PHP version: 5.2.13
Package: Date/time related
Bug Type: Bug
Bug description:Datetime fails to parse an ISO 8601 ordinal date (extended
format)
Description:
PHP 5.2.12 with Suhosin-Patch 0.9.7 (cli) (built: Dec 30 2009 15:41:26)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies
with Zend Optimizer v3.3.9, Copyright (c) 1998-2009, by Zend
Technologies
Test script:
---
// Ordinal date â 12 April 1985
$d1 = new Datetime('1985102');
// OK
$d2 = new Datetime('1985-102');
// Exception: DateTime::__construct(): Failed to parse time string
(1985-102) at position 7 (2): Unexpected character
--
Edit bug report at http://bugs.php.net/bug.php?id=51987&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51987&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51987&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=51987&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=51987&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51987&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51987&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51987&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51987&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51987&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51987&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51987&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51987&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51987&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51987&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51987&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51987&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51987&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51987&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51987&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51987&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51987&r=mysqlcfg
Req #51717 [Csd->Bgs]: Replace in-browser javascript terp with php terp
Edit report at http://bugs.php.net/bug.php?id=51717&edit=1 ID: 51717 Updated by: paj...@php.net Reported by: scratch65535 at att dot net Summary: Replace in-browser javascript terp with php terp -Status: Closed +Status: Bogus Type: Feature/Change Request Package: Unknown/Other Function Operating System: any/all PHP Version: Irrelevant Assigned To: sjoerd Previous Comments: [2010-06-03 13:21:17] sjo...@php.net While I agree with you that Javascript leaves room for improvement, your desire to use PHP in the browser is not going to see the light of day within the PHP project. This feature would so big and separate from the current PHP implementation that it would be its own project. Of course, you are welcome to start such a project. [2010-05-01 17:25:18] scratch65535 at att dot net Description: PHP is already far more stable and solidly defined than Javascript or any of its permutations is. That advantage will continue through the foreseeable future. Providing a browser-resident php terp would allow people to exploit their php experience to create client-side javascript-type functionality without actually having to struggle with all the javascript craziness. (Just a data point from personal experience: I've been programming since 1975, in everything from 8-bit Basic to CDC CP & PP assembly languages. After a month of struggle, I gave up on trying to add javascript functionality to my php apps. The evidence suggests that the language was designed by a kitten with a ball of yarn.) -- Edit this bug report at http://bugs.php.net/bug.php?id=51717&edit=1
Bug->Req #51934 [Opn]: strtotime plurals / incorrect time
Edit report at http://bugs.php.net/bug.php?id=51934&edit=1
ID: 51934
Updated by: der...@php.net
Reported by: brent dot hansen at gmail dot com
Summary: strtotime plurals / incorrect time
Status: Open
-Type: Bug
+Type: Feature/Change Request
Package: Date/time related
Operating System: Win 7 Pro
PHP Version: 5.3.2
-Assigned To:
+Assigned To: derick
New Comment:
Changing this to a feature request instead
Previous Comments:
[2010-06-03 13:11:43] sjo...@php.net
It interprets the S as Sierra Time Zone. Similar to:
echo date("Y-m-d H:i:s",strtotime("4 SundayPST ago"));
[2010-05-27 19:18:54] brent dot hansen at gmail dot com
Description:
Pluralization seems to remove 1 hour from calculation or drops daylight
savings adjustment.
Notes:
date.timezone = America/Los_Angeles
Correction to PHP version: 5.3.1
Test script:
---
date("Y-m-d H:i:s",strtotime("4 Sunday ago"));
date("Y-m-d H:i:s",strtotime("4 Sundays ago"));
Expected result:
2010-05-01 00:00:00
2010-05-01 00:00:00
Actual result:
--
2010-05-01 00:00:00
2010-04-30 23:00:00
--
Edit this bug report at http://bugs.php.net/bug.php?id=51934&edit=1
Req #51717 [Opn->Csd]: Replace in-browser javascript terp with php terp
Edit report at http://bugs.php.net/bug.php?id=51717&edit=1 ID: 51717 Updated by: sjo...@php.net Reported by: scratch65535 at att dot net Summary: Replace in-browser javascript terp with php terp -Status: Open +Status: Closed Type: Feature/Change Request Package: Unknown/Other Function Operating System: any/all PHP Version: Irrelevant -Assigned To: +Assigned To: sjoerd New Comment: While I agree with you that Javascript leaves room for improvement, your desire to use PHP in the browser is not going to see the light of day within the PHP project. This feature would so big and separate from the current PHP implementation that it would be its own project. Of course, you are welcome to start such a project. Previous Comments: [2010-05-01 17:25:18] scratch65535 at att dot net Description: PHP is already far more stable and solidly defined than Javascript or any of its permutations is. That advantage will continue through the foreseeable future. Providing a browser-resident php terp would allow people to exploit their php experience to create client-side javascript-type functionality without actually having to struggle with all the javascript craziness. (Just a data point from personal experience: I've been programming since 1975, in everything from 8-bit Basic to CDC CP & PP assembly languages. After a month of struggle, I gave up on trying to add javascript functionality to my php apps. The evidence suggests that the language was designed by a kitten with a ball of yarn.) -- Edit this bug report at http://bugs.php.net/bug.php?id=51717&edit=1
Req #51984 [Csd->Bgs]: new operation ?= for $var = $var ? $var :"hello world"
Edit report at http://bugs.php.net/bug.php?id=51984&edit=1 ID: 51984 Updated by: paj...@php.net Reported by: fortruth at mabang dot net Summary: new operation ?= for $var = $var ? $var :"hello world" -Status: Closed +Status: Bogus Type:Feature/Change Request Package: Scripting Engine problem PHP Version: trunk-SVN-2010-06-03 (SVN) Assigned To: sjoerd New Comment: not really, we have ?: now, which does mostly what is requested here. Previous Comments: [2010-06-03 13:04:01] sjo...@php.net The ifsetor operator is planned for PHP6: http://www.php.net/~derick/meeting-notes.html#ifsetor-as-replacement-for-foo- isset-foo-foo-something-else [2010-06-03 09:27:29] fortruth at mabang dot net and this maybe more useful for stand for: if(ï¼$var)$var = "hello world"; [2010-06-03 08:52:13] fortruth at mabang dot net Description: as you have make ?: more easy. but I think there can be a more easy for other one. like $var ?= "hello world"; there can be equal that $var = $var ? $var : "hello world"; for now short is $var = $var ? : "hello world"; -- Edit this bug report at http://bugs.php.net/bug.php?id=51984&edit=1
Bug #51934 [Opn]: strtotime plurals / incorrect time
Edit report at http://bugs.php.net/bug.php?id=51934&edit=1
ID: 51934
Updated by: sjo...@php.net
Reported by: brent dot hansen at gmail dot com
Summary: strtotime plurals / incorrect time
Status: Open
Type: Bug
Package: Date/time related
Operating System: Win 7 Pro
PHP Version: 5.3.2
New Comment:
It interprets the S as Sierra Time Zone. Similar to:
echo date("Y-m-d H:i:s",strtotime("4 SundayPST ago"));
Previous Comments:
[2010-05-27 19:18:54] brent dot hansen at gmail dot com
Description:
Pluralization seems to remove 1 hour from calculation or drops daylight
savings adjustment.
Notes:
date.timezone = America/Los_Angeles
Correction to PHP version: 5.3.1
Test script:
---
date("Y-m-d H:i:s",strtotime("4 Sunday ago"));
date("Y-m-d H:i:s",strtotime("4 Sundays ago"));
Expected result:
2010-05-01 00:00:00
2010-05-01 00:00:00
Actual result:
--
2010-05-01 00:00:00
2010-04-30 23:00:00
--
Edit this bug report at http://bugs.php.net/bug.php?id=51934&edit=1
Bug #51972 [Opn->Fbk]: PHP 5.3.x bug Require_once don't work with RELATIVE symbolic link
Edit report at http://bugs.php.net/bug.php?id=51972&edit=1 ID: 51972 Updated by: sjo...@php.net Reported by: jacques dot moati at happyend dot fr Summary: PHP 5.3.x bug Require_once don't work with RELATIVE symbolic link -Status: Open +Status: Feedback Type: Bug Package: *General Issues Operating System: Ubuntu Lucid Lynx PHP Version: 5.3.2 New Comment: Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. I could not reproduce the problem. Previous Comments: [2010-06-02 11:04:19] jacques dot moati at happyend dot fr Description: Hello, This bug is present into all 5.3 php version. I test it in the ubuntu package, php 5.3 stable and snap version with --disable-all for ./config compilation. When you include a file in a relative (eg ../) symbolic link directory, PHP don't include it and do a FATAL error. files_existes and is_readable return true ... If the symbolic link of the diectory is absolute, the include work correctly ... -- Edit this bug report at http://bugs.php.net/bug.php?id=51972&edit=1
Req #51984 [Opn->Csd]: new operation ?= for $var = $var ? $var :"hello world"
Edit report at http://bugs.php.net/bug.php?id=51984&edit=1 ID: 51984 Updated by: sjo...@php.net Reported by: fortruth at mabang dot net Summary: new operation ?= for $var = $var ? $var :"hello world" -Status: Open +Status: Closed Type:Feature/Change Request Package: Scripting Engine problem PHP Version: trunk-SVN-2010-06-03 (SVN) -Assigned To: +Assigned To: sjoerd New Comment: The ifsetor operator is planned for PHP6: http://www.php.net/~derick/meeting-notes.html#ifsetor-as-replacement-for-foo- isset-foo-foo-something-else Previous Comments: [2010-06-03 09:27:29] fortruth at mabang dot net and this maybe more useful for stand for: if(ï¼$var)$var = "hello world"; [2010-06-03 08:52:13] fortruth at mabang dot net Description: as you have make ?: more easy. but I think there can be a more easy for other one. like $var ?= "hello world"; there can be equal that $var = $var ? $var : "hello world"; for now short is $var = $var ? : "hello world"; -- Edit this bug report at http://bugs.php.net/bug.php?id=51984&edit=1
Bug #51986 [Opn]: array_filter breaks references when a callback is used
Edit report at http://bugs.php.net/bug.php?id=51986&edit=1
ID: 51986
Updated by: sjo...@php.net
Reported by: daniel dot menard at ehesp dot fr
Summary: array_filter breaks references when a callback is used
Status: Open
Type: Bug
Package: Arrays related
Operating System: Windows XP
PHP Version: 5.3.2
New Comment:
Use a reference in your callback function:
function my_trim(& $a)
{
return trim($a);
}
Previous Comments:
[2010-06-03 12:28:24] daniel dot menard at ehesp dot fr
Description:
I have an array and a variable which is a reference on some element in
this array:
$arr=array('a'); $ref = &$arr[0]
If I apply array_filter() with a callback like trim() or count() on the
array, the reference is broken and $ref is no longer a reference (If I
apply array_filter() without a callback, the reference is not altered
and the result is correct).
I think that this is a regression introduced in php 5.2.11: with the
test script below, 5.2.10 give the good result, 5.2.11 do not.
I also tested with the latest version (5.3.2): same result, reference is
broken.
PS: I tested on windows XP with packages php-5.x.y-Win32-VC6-x86.zip
provided on this page:
http://windows.php.net/downloads/releases/archives/
Test script:
---
// Init
$arr = array('some value');
$ref = & $arr[0];
// Change $arr
$arr[0] = 'ONE';
echo 'step 1. $ref is ', ($ref !== 'ONE') ? 'BROKEN' : 'OK', "\n";
// Apply array_filter (without callback) and change $arr
array_filter($arr);
$arr[0] = 'TWO';
echo 'step 2. $ref is ', ($ref !== 'TWO') ? 'BROKEN' : 'OK', "\n";
// Apply array_filter (with a callback) then change $arr
array_filter($arr,'trim');
$arr[0] = 'THREE';
echo 'step 3. $ref is ', ($ref !== 'THREE') ? 'BROKEN' : 'OK', "\n";
Expected result:
step 1. $ref is OK
step 2. $ref is OK
step 3. $ref is OK
Actual result:
--
step 1. $ref is OK
step 2. $ref is OK
step 3. $ref is BROKEN
--
Edit this bug report at http://bugs.php.net/bug.php?id=51986&edit=1
[PHP-BUG] Bug #51986 [NEW]: array_filter breaks references when a callback is used
From:
Operating system: Windows XP
PHP version: 5.3.2
Package: Arrays related
Bug Type: Bug
Bug description:array_filter breaks references when a callback is used
Description:
I have an array and a variable which is a reference on some element in this
array:
$arr=array('a'); $ref = &$arr[0]
If I apply array_filter() with a callback like trim() or count() on the
array, the reference is broken and $ref is no longer a reference (If I
apply array_filter() without a callback, the reference is not altered and
the result is correct).
I think that this is a regression introduced in php 5.2.11: with the test
script below, 5.2.10 give the good result, 5.2.11 do not.
I also tested with the latest version (5.3.2): same result, reference is
broken.
PS: I tested on windows XP with packages php-5.x.y-Win32-VC6-x86.zip
provided on this page: http://windows.php.net/downloads/releases/archives/
Test script:
---
// Init
$arr = array('some value');
$ref = & $arr[0];
// Change $arr
$arr[0] = 'ONE';
echo 'step 1. $ref is ', ($ref !== 'ONE') ? 'BROKEN' : 'OK', "\n";
// Apply array_filter (without callback) and change $arr
array_filter($arr);
$arr[0] = 'TWO';
echo 'step 2. $ref is ', ($ref !== 'TWO') ? 'BROKEN' : 'OK', "\n";
// Apply array_filter (with a callback) then change $arr
array_filter($arr,'trim');
$arr[0] = 'THREE';
echo 'step 3. $ref is ', ($ref !== 'THREE') ? 'BROKEN' : 'OK', "\n";
Expected result:
step 1. $ref is OK
step 2. $ref is OK
step 3. $ref is OK
Actual result:
--
step 1. $ref is OK
step 2. $ref is OK
step 3. $ref is BROKEN
--
Edit bug report at http://bugs.php.net/bug.php?id=51986&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51986&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51986&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=51986&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=51986&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51986&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51986&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51986&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51986&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51986&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51986&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51986&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51986&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51986&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51986&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51986&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51986&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51986&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51986&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51986&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51986&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51986&r=mysqlcfg
[PHP-BUG] Bug #51985 [NEW]: The signature or decryption was invalid
From:
Operating system: Linux Debian
PHP version: 5.3.2
Package: SOAP related
Bug Type: Bug
Bug description:The signature or decryption was invalid
Description:
I have to communicate a SOAP server which is need 2 different SSL
key/passphrase.
I need one to allow communicate the server, and I need an other one to sign
the
xml which I send.
When I add a wrong SLL key to communicate then I can't connect to the
host.
When I add a wrong SSL key to sign the xml I keep the following error: "The
signature or decryption was invalid"
So I think the __soapCall method use the SSL key(wich meant to be auth) to
sign
the xml and that's why I keep the same error when I directly use a wrong
key.
But this is just a guess.
I don't know why it is not working.
Test script:
---
$clientOps["local_cert"] = "/var/www/wsdl/key/test.pem";
$clientOps["passphrase"] = "test";
$client = new WSSecSoapClient("test.wsdl", $clientOps);
$xml = "
http://www.w3.org/2001/XMLSchema-instance\";
xmlns:xsd=\"http://www.w3.org/2001/XMLSchema\";
xmlns:soap=\"http://schemas.xmlsoap.org/soap/envelope/\";>
";
working:
$answer =
$client->__doRequest($xml,"https://secured.url/test.asmx","HelloWorld","1.1";);
NOT working:
$answer = $client->__soapCall("HelloWorld", array(),
array("location"=>"https://secured.url/test.asmx";));
Expected result:
When I call the __doRequest method then I keep a valid answer. Which is
contains
"Hello World!"
I expect the same result when I call __soapCall method.
Actual result:
--
SoapFault exception: [q0:FailedCheck] The signature or decryption was
invalid in
/var/www/index.php:49
Stack trace:
#0 /var/www/index.php(49): SoapClient->__soapCall('HelloWorld', Array,
Array)
#1 {main}
--
Edit bug report at http://bugs.php.net/bug.php?id=51985&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51985&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51985&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=51985&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=51985&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51985&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51985&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51985&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51985&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51985&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51985&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51985&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51985&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51985&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51985&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51985&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51985&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51985&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51985&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51985&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51985&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51985&r=mysqlcfg
Req #51984 [Com]: new operation ?= for $var = $var ? $var :"hello world"
Edit report at http://bugs.php.net/bug.php?id=51984&edit=1 ID: 51984 Comment by: fortruth at mabang dot net Reported by: fortruth at mabang dot net Summary: new operation ?= for $var = $var ? $var :"hello world" Status: Open Type:Feature/Change Request Package: Scripting Engine problem PHP Version: trunk-SVN-2010-06-03 (SVN) New Comment: and this maybe more useful for stand for: if(ï¼$var)$var = "hello world"; Previous Comments: [2010-06-03 08:52:13] fortruth at mabang dot net Description: as you have make ?: more easy. but I think there can be a more easy for other one. like $var ?= "hello world"; there can be equal that $var = $var ? $var : "hello world"; for now short is $var = $var ? : "hello world"; -- Edit this bug report at http://bugs.php.net/bug.php?id=51984&edit=1
