Bug #53632 [Csd]: PHP hangs on numeric value 2.2250738585072011e-308
Edit report at http://bugs.php.net/bug.php?id=53632&edit=1 ID: 53632 Updated by: paj...@php.net Reported by:exploringbinary at gmail dot com Summary:PHP hangs on numeric value 2.2250738585072011e-308 Status: Closed Type: Bug Package:Math related PHP Version:5.3.4 Assigned To:scottmac Block user comment: N Private report: N New Comment: Seems that the commit did not make it here: Fix: http://svn.php.net/viewvc?view=revision&revision=307095 Test case: http://svn.php.net/viewvc?view=revision&revision=307097 Previous Comments: [2011-01-05 00:47:43] paj...@php.net My bad, forgot to revert a change in my previous attempt to fix this issue. Fresh co & build works, tests pass. [2011-01-05 00:36:58] scott...@php.net Automatic comment from SVN on behalf of scottmac Revision: http://svn.php.net/viewvc/?view=revision&revision=307097 Log: Add test for bug #53632 [2011-01-05 00:33:37] paj...@php.net Taking the hand, another bug (crash) happens here. Will post bt&co as soon as possible. [2011-01-05 00:19:33] scott...@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. [2011-01-04 23:36:26] scott...@php.net Automatic comment from SVN on behalf of scottmac Revision: http://svn.php.net/viewvc/?view=revision&revision=307095 Log: Fix bug #53632 with x87 fpu 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=53632 -- Edit this bug report at http://bugs.php.net/bug.php?id=53632&edit=1
Bug #53632 [Com]: PHP hangs on numeric value 2.2250738585072011e-308
Edit report at http://bugs.php.net/bug.php?id=53632&edit=1 ID: 53632 Comment by: zdv2010 at gmail dot com Reported by:exploringbinary at gmail dot com Summary:PHP hangs on numeric value 2.2250738585072011e-308 Status: Closed Type: Bug Package:Math related PHP Version:5.3.4 Assigned To:scottmac Block user comment: N Private report: N New Comment: I have this problem on PHP-5.2.14 on Windows XP SP3 C:\Documents and Settings\user>php -v PHP 5.2.14 (cli) (built: Jul 21 2010 18:43:55) Copyright (c) 1997-2010 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2010 Zend Technologies Previous Comments: [2011-01-05 09:50:21] paj...@php.net Seems that the commit did not make it here: Fix: http://svn.php.net/viewvc?view=revision&revision=307095 Test case: http://svn.php.net/viewvc?view=revision&revision=307097 [2011-01-05 00:47:43] paj...@php.net My bad, forgot to revert a change in my previous attempt to fix this issue. Fresh co & build works, tests pass. [2011-01-05 00:36:58] scott...@php.net Automatic comment from SVN on behalf of scottmac Revision: http://svn.php.net/viewvc/?view=revision&revision=307097 Log: Add test for bug #53632 [2011-01-05 00:33:37] paj...@php.net Taking the hand, another bug (crash) happens here. Will post bt&co as soon as possible. [2011-01-05 00:19:33] scott...@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. 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=53632 -- Edit this bug report at http://bugs.php.net/bug.php?id=53632&edit=1
Bug #53651 [Asn->Fbk]: Under mysqlnd, mysqli_affected_rows() returns 0
Edit report at http://bugs.php.net/bug.php?id=53651&edit=1 ID: 53651 Updated by: and...@php.net Reported by:marc at phpmyadmin dot net Summary:Under mysqlnd, mysqli_affected_rows() returns 0 -Status: Assigned +Status: Feedback Type: Bug Package:MySQLi related Operating System: Linux PHP Version:5.3.4 Assigned To:mysql Block user comment: N Private report: N New Comment: I can't reproduce it. Maybe it's bogus due to something else. Here are my results : myslqnd + MySQL 5.5.8 (executed twice in a row) and...@poohie:/work/vanilla/php/php-src/branches/PHP_5_3$ ./php b.php Affected rows (UPDATE): 1 and...@poohie:/work/vanilla/php/php-src/branches/PHP_5_3$ ./php b.php Affected rows (UPDATE): 0 myslqnd + MySQL 5.1-dev (executed twice in a row) and...@poohie:/work/vanilla/php/php-src/branches/PHP_5_3$ ./php b.php Affected rows (UPDATE): 1 and...@poohie:/work/vanilla/php/php-src/branches/PHP_5_3$ ./php b.php Affected rows (UPDATE): 0 As you see, the second time the result is 0. Why? It is a feature or gotcha of MySQL. If the row doesn't change affected_rows is 0. And the row doesn't change from toto to toto there is no change, thus the row is left intact. Previous Comments: [2011-01-04 19:08:06] marc at phpmyadmin dot net Description: In PHP 5.3.4 (also 5.3.3 and 5.3.2), connecting to MySQL 5.1.49 with mysqli extension under mysqlnd, I always obtain 0 as the result of mysqli_affected_rows() following an UPDATE that changed one row. Works fine under PHP 5.2.14 + MySQL 5.1.49 client library. Thanks, Marc Delisle Test script: --- Expected result: Affected rows (UPDATE): 1 Actual result: -- Affected rows (UPDATE): 0 -- Edit this bug report at http://bugs.php.net/bug.php?id=53651&edit=1
Bug #53651 [Fbk->Asn]: Under mysqlnd, mysqli_affected_rows() returns 0
Edit report at http://bugs.php.net/bug.php?id=53651&edit=1 ID: 53651 User updated by:marc at phpmyadmin dot net Reported by:marc at phpmyadmin dot net Summary:Under mysqlnd, mysqli_affected_rows() returns 0 -Status: Feedback +Status: Assigned Type: Bug Package:MySQLi related Operating System: Linux PHP Version:5.3.4 Assigned To:mysql Block user comment: N Private report: N New Comment: Hi Andrey, here is my configuration, maybe the presence of PDO has an impact? ./configure --with-apxs2=/usr/local/apache2/bin/apxs \ --with-libdir=lib64 \ --disable-debug \ --enable-calendar \ --with-gd=shared \ --with-freetype-dir \ --with-mysql=shared,mysqlnd \ --with-mysqli=shared,mysqlnd \ --with-regex=php \ --with-png-dir=/usr/lib \ --with-zlib=shared \ --with-iconv=shared \ --enable-ftp \ --with-mcrypt=shared \ --with-bz2=shared \ --enable-zip \ --with-jpeg-dir=/usr/lib \ --enable-mbstring \ --without-sqlite \ --enable-dom \ --enable-json \ --enable-pdo=shared \ --with-pdo-mysql=shared,mysqlnd \ --without-pdo-sqlite \ --with-pear \ --enable-spl \ --enable-bcmath \ --with-curl=shared \ --with-ldap=shared,/usr \ --with-gettext=shared \ --with-snmp=shared \ --enable-sockets Previous Comments: [2011-01-05 10:31:08] and...@php.net I can't reproduce it. Maybe it's bogus due to something else. Here are my results : myslqnd + MySQL 5.5.8 (executed twice in a row) and...@poohie:/work/vanilla/php/php-src/branches/PHP_5_3$ ./php b.php Affected rows (UPDATE): 1 and...@poohie:/work/vanilla/php/php-src/branches/PHP_5_3$ ./php b.php Affected rows (UPDATE): 0 myslqnd + MySQL 5.1-dev (executed twice in a row) and...@poohie:/work/vanilla/php/php-src/branches/PHP_5_3$ ./php b.php Affected rows (UPDATE): 1 and...@poohie:/work/vanilla/php/php-src/branches/PHP_5_3$ ./php b.php Affected rows (UPDATE): 0 As you see, the second time the result is 0. Why? It is a feature or gotcha of MySQL. If the row doesn't change affected_rows is 0. And the row doesn't change from toto to toto there is no change, thus the row is left intact. [2011-01-04 19:08:06] marc at phpmyadmin dot net Description: In PHP 5.3.4 (also 5.3.3 and 5.3.2), connecting to MySQL 5.1.49 with mysqli extension under mysqlnd, I always obtain 0 as the result of mysqli_affected_rows() following an UPDATE that changed one row. Works fine under PHP 5.2.14 + MySQL 5.1.49 client library. Thanks, Marc Delisle Test script: --- Expected result: Affected rows (UPDATE): 1 Actual result: -- Affected rows (UPDATE): 0 -- Edit this bug report at http://bugs.php.net/bug.php?id=53651&edit=1
Bug #53651 [Asn->Fbk]: Under mysqlnd, mysqli_affected_rows() returns 0
Edit report at http://bugs.php.net/bug.php?id=53651&edit=1 ID: 53651 Updated by: and...@php.net Reported by:marc at phpmyadmin dot net Summary:Under mysqlnd, mysqli_affected_rows() returns 0 -Status: Assigned +Status: Feedback Type: Bug Package:MySQLi related Operating System: Linux PHP Version:5.3.4 Assigned To:mysql Block user comment: N Private report: N New Comment: Can you post output from the script with freshly created table and freshly inserted row. Please, run the script twice. Thanks! Previous Comments: [2011-01-05 12:00:16] marc at phpmyadmin dot net Hi Andrey, here is my configuration, maybe the presence of PDO has an impact? ./configure --with-apxs2=/usr/local/apache2/bin/apxs \ --with-libdir=lib64 \ --disable-debug \ --enable-calendar \ --with-gd=shared \ --with-freetype-dir \ --with-mysql=shared,mysqlnd \ --with-mysqli=shared,mysqlnd \ --with-regex=php \ --with-png-dir=/usr/lib \ --with-zlib=shared \ --with-iconv=shared \ --enable-ftp \ --with-mcrypt=shared \ --with-bz2=shared \ --enable-zip \ --with-jpeg-dir=/usr/lib \ --enable-mbstring \ --without-sqlite \ --enable-dom \ --enable-json \ --enable-pdo=shared \ --with-pdo-mysql=shared,mysqlnd \ --without-pdo-sqlite \ --with-pear \ --enable-spl \ --enable-bcmath \ --with-curl=shared \ --with-ldap=shared,/usr \ --with-gettext=shared \ --with-snmp=shared \ --enable-sockets [2011-01-05 10:31:08] and...@php.net I can't reproduce it. Maybe it's bogus due to something else. Here are my results : myslqnd + MySQL 5.5.8 (executed twice in a row) and...@poohie:/work/vanilla/php/php-src/branches/PHP_5_3$ ./php b.php Affected rows (UPDATE): 1 and...@poohie:/work/vanilla/php/php-src/branches/PHP_5_3$ ./php b.php Affected rows (UPDATE): 0 myslqnd + MySQL 5.1-dev (executed twice in a row) and...@poohie:/work/vanilla/php/php-src/branches/PHP_5_3$ ./php b.php Affected rows (UPDATE): 1 and...@poohie:/work/vanilla/php/php-src/branches/PHP_5_3$ ./php b.php Affected rows (UPDATE): 0 As you see, the second time the result is 0. Why? It is a feature or gotcha of MySQL. If the row doesn't change affected_rows is 0. And the row doesn't change from toto to toto there is no change, thus the row is left intact. [2011-01-04 19:08:06] marc at phpmyadmin dot net Description: In PHP 5.3.4 (also 5.3.3 and 5.3.2), connecting to MySQL 5.1.49 with mysqli extension under mysqlnd, I always obtain 0 as the result of mysqli_affected_rows() following an UPDATE that changed one row. Works fine under PHP 5.2.14 + MySQL 5.1.49 client library. Thanks, Marc Delisle Test script: --- Expected result: Affected rows (UPDATE): 1 Actual result: -- Affected rows (UPDATE): 0 -- Edit this bug report at http://bugs.php.net/bug.php?id=53651&edit=1
Bug #53651 [Fbk->Asn]: Under mysqlnd, mysqli_affected_rows() returns 0
Edit report at http://bugs.php.net/bug.php?id=53651&edit=1 ID: 53651 User updated by:marc at phpmyadmin dot net Reported by:marc at phpmyadmin dot net Summary:Under mysqlnd, mysqli_affected_rows() returns 0 -Status: Feedback +Status: Assigned Type: Bug Package:MySQLi related Operating System: Linux PHP Version:5.3.4 Assigned To:mysql Block user comment: N Private report: N New Comment: Andrey, I had a permission problem at MySQL level that produced the "0" output. Now I can no longer reproduce the problem with the test script, but I still have this problem in phpMyAdmin. I'll try to come up with a new test script. Previous Comments: [2011-01-05 12:08:52] and...@php.net Can you post output from the script with freshly created table and freshly inserted row. Please, run the script twice. Thanks! [2011-01-05 12:00:16] marc at phpmyadmin dot net Hi Andrey, here is my configuration, maybe the presence of PDO has an impact? ./configure --with-apxs2=/usr/local/apache2/bin/apxs \ --with-libdir=lib64 \ --disable-debug \ --enable-calendar \ --with-gd=shared \ --with-freetype-dir \ --with-mysql=shared,mysqlnd \ --with-mysqli=shared,mysqlnd \ --with-regex=php \ --with-png-dir=/usr/lib \ --with-zlib=shared \ --with-iconv=shared \ --enable-ftp \ --with-mcrypt=shared \ --with-bz2=shared \ --enable-zip \ --with-jpeg-dir=/usr/lib \ --enable-mbstring \ --without-sqlite \ --enable-dom \ --enable-json \ --enable-pdo=shared \ --with-pdo-mysql=shared,mysqlnd \ --without-pdo-sqlite \ --with-pear \ --enable-spl \ --enable-bcmath \ --with-curl=shared \ --with-ldap=shared,/usr \ --with-gettext=shared \ --with-snmp=shared \ --enable-sockets [2011-01-05 10:31:08] and...@php.net I can't reproduce it. Maybe it's bogus due to something else. Here are my results : myslqnd + MySQL 5.5.8 (executed twice in a row) and...@poohie:/work/vanilla/php/php-src/branches/PHP_5_3$ ./php b.php Affected rows (UPDATE): 1 and...@poohie:/work/vanilla/php/php-src/branches/PHP_5_3$ ./php b.php Affected rows (UPDATE): 0 myslqnd + MySQL 5.1-dev (executed twice in a row) and...@poohie:/work/vanilla/php/php-src/branches/PHP_5_3$ ./php b.php Affected rows (UPDATE): 1 and...@poohie:/work/vanilla/php/php-src/branches/PHP_5_3$ ./php b.php Affected rows (UPDATE): 0 As you see, the second time the result is 0. Why? It is a feature or gotcha of MySQL. If the row doesn't change affected_rows is 0. And the row doesn't change from toto to toto there is no change, thus the row is left intact. [2011-01-04 19:08:06] marc at phpmyadmin dot net Description: In PHP 5.3.4 (also 5.3.3 and 5.3.2), connecting to MySQL 5.1.49 with mysqli extension under mysqlnd, I always obtain 0 as the result of mysqli_affected_rows() following an UPDATE that changed one row. Works fine under PHP 5.2.14 + MySQL 5.1.49 client library. Thanks, Marc Delisle Test script: --- Expected result: Affected rows (UPDATE): 1 Actual result: -- Affected rows (UPDATE): 0 -- Edit this bug report at http://bugs.php.net/bug.php?id=53651&edit=1
Bug #53651 [Asn]: Under mysqlnd, mysqli_affected_rows() returns 0
Edit report at http://bugs.php.net/bug.php?id=53651&edit=1 ID: 53651 Updated by: u...@php.net Reported by:marc at phpmyadmin dot net Summary:Under mysqlnd, mysqli_affected_rows() returns 0 Status: Assigned Type: Bug Package:MySQLi related Operating System: Linux PHP Version:5.3.4 Assigned To:mysql Block user comment: N Private report: N New Comment: No, neither adding PDO nor the moon phase can impact it. Previous Comments: [2011-01-05 12:28:57] marc at phpmyadmin dot net Andrey, I had a permission problem at MySQL level that produced the "0" output. Now I can no longer reproduce the problem with the test script, but I still have this problem in phpMyAdmin. I'll try to come up with a new test script. [2011-01-05 12:08:52] and...@php.net Can you post output from the script with freshly created table and freshly inserted row. Please, run the script twice. Thanks! [2011-01-05 12:00:16] marc at phpmyadmin dot net Hi Andrey, here is my configuration, maybe the presence of PDO has an impact? ./configure --with-apxs2=/usr/local/apache2/bin/apxs \ --with-libdir=lib64 \ --disable-debug \ --enable-calendar \ --with-gd=shared \ --with-freetype-dir \ --with-mysql=shared,mysqlnd \ --with-mysqli=shared,mysqlnd \ --with-regex=php \ --with-png-dir=/usr/lib \ --with-zlib=shared \ --with-iconv=shared \ --enable-ftp \ --with-mcrypt=shared \ --with-bz2=shared \ --enable-zip \ --with-jpeg-dir=/usr/lib \ --enable-mbstring \ --without-sqlite \ --enable-dom \ --enable-json \ --enable-pdo=shared \ --with-pdo-mysql=shared,mysqlnd \ --without-pdo-sqlite \ --with-pear \ --enable-spl \ --enable-bcmath \ --with-curl=shared \ --with-ldap=shared,/usr \ --with-gettext=shared \ --with-snmp=shared \ --enable-sockets [2011-01-05 10:31:08] and...@php.net I can't reproduce it. Maybe it's bogus due to something else. Here are my results : myslqnd + MySQL 5.5.8 (executed twice in a row) and...@poohie:/work/vanilla/php/php-src/branches/PHP_5_3$ ./php b.php Affected rows (UPDATE): 1 and...@poohie:/work/vanilla/php/php-src/branches/PHP_5_3$ ./php b.php Affected rows (UPDATE): 0 myslqnd + MySQL 5.1-dev (executed twice in a row) and...@poohie:/work/vanilla/php/php-src/branches/PHP_5_3$ ./php b.php Affected rows (UPDATE): 1 and...@poohie:/work/vanilla/php/php-src/branches/PHP_5_3$ ./php b.php Affected rows (UPDATE): 0 As you see, the second time the result is 0. Why? It is a feature or gotcha of MySQL. If the row doesn't change affected_rows is 0. And the row doesn't change from toto to toto there is no change, thus the row is left intact. [2011-01-04 19:08:06] marc at phpmyadmin dot net Description: In PHP 5.3.4 (also 5.3.3 and 5.3.2), connecting to MySQL 5.1.49 with mysqli extension under mysqlnd, I always obtain 0 as the result of mysqli_affected_rows() following an UPDATE that changed one row. Works fine under PHP 5.2.14 + MySQL 5.1.49 client library. Thanks, Marc Delisle Test script: --- Expected result: Affected rows (UPDATE): 1 Actual result: -- Affected rows (UPDATE): 0 -- Edit this bug report at http://bugs.php.net/bug.php?id=53651&edit=1
Bug #53651 [Asn->Csd]: Under mysqlnd, mysqli_affected_rows() returns 0
Edit report at http://bugs.php.net/bug.php?id=53651&edit=1 ID: 53651 User updated by:marc at phpmyadmin dot net Reported by:marc at phpmyadmin dot net Summary:Under mysqlnd, mysqli_affected_rows() returns 0 -Status: Assigned +Status: Closed Type: Bug Package:MySQLi related Operating System: Linux PHP Version:5.3.4 Assigned To:mysql Block user comment: N Private report: N New Comment: Sorry for the disturbance. Previous Comments: [2011-01-05 13:34:49] u...@php.net No, neither adding PDO nor the moon phase can impact it. [2011-01-05 12:28:57] marc at phpmyadmin dot net Andrey, I had a permission problem at MySQL level that produced the "0" output. Now I can no longer reproduce the problem with the test script, but I still have this problem in phpMyAdmin. I'll try to come up with a new test script. [2011-01-05 12:08:52] and...@php.net Can you post output from the script with freshly created table and freshly inserted row. Please, run the script twice. Thanks! [2011-01-05 12:00:16] marc at phpmyadmin dot net Hi Andrey, here is my configuration, maybe the presence of PDO has an impact? ./configure --with-apxs2=/usr/local/apache2/bin/apxs \ --with-libdir=lib64 \ --disable-debug \ --enable-calendar \ --with-gd=shared \ --with-freetype-dir \ --with-mysql=shared,mysqlnd \ --with-mysqli=shared,mysqlnd \ --with-regex=php \ --with-png-dir=/usr/lib \ --with-zlib=shared \ --with-iconv=shared \ --enable-ftp \ --with-mcrypt=shared \ --with-bz2=shared \ --enable-zip \ --with-jpeg-dir=/usr/lib \ --enable-mbstring \ --without-sqlite \ --enable-dom \ --enable-json \ --enable-pdo=shared \ --with-pdo-mysql=shared,mysqlnd \ --without-pdo-sqlite \ --with-pear \ --enable-spl \ --enable-bcmath \ --with-curl=shared \ --with-ldap=shared,/usr \ --with-gettext=shared \ --with-snmp=shared \ --enable-sockets [2011-01-05 10:31:08] and...@php.net I can't reproduce it. Maybe it's bogus due to something else. Here are my results : myslqnd + MySQL 5.5.8 (executed twice in a row) and...@poohie:/work/vanilla/php/php-src/branches/PHP_5_3$ ./php b.php Affected rows (UPDATE): 1 and...@poohie:/work/vanilla/php/php-src/branches/PHP_5_3$ ./php b.php Affected rows (UPDATE): 0 myslqnd + MySQL 5.1-dev (executed twice in a row) and...@poohie:/work/vanilla/php/php-src/branches/PHP_5_3$ ./php b.php Affected rows (UPDATE): 1 and...@poohie:/work/vanilla/php/php-src/branches/PHP_5_3$ ./php b.php Affected rows (UPDATE): 0 As you see, the second time the result is 0. Why? It is a feature or gotcha of MySQL. If the row doesn't change affected_rows is 0. And the row doesn't change from toto to toto there is no change, thus the row is left intact. 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=53651 -- Edit this bug report at http://bugs.php.net/bug.php?id=53651&edit=1
Bug #53632 [Com]: PHP hangs on numeric value 2.2250738585072011e-308
Edit report at http://bugs.php.net/bug.php?id=53632&edit=1 ID: 53632 Comment by: tyra3l at gmail dot com Reported by:exploringbinary at gmail dot com Summary:PHP hangs on numeric value 2.2250738585072011e-308 Status: Closed Type: Bug Package:Math related PHP Version:5.3.4 Assigned To:scottmac Block user comment: N Private report: N New Comment: Just for the record, because some of my friends missed this: max_execution_time/set_time_limit cannot help you with this problem, because it's only gets checked between two userland instructions, hence this won't happen in this case. Tyrael Previous Comments: [2011-01-05 14:35:27] johan...@php.net Automatic comment from SVN on behalf of johannes Revision: http://svn.php.net/viewvc/?view=revision&revision=307120 Log: Merge rev. 307097 Add test for bug #53632 (scottmac) [2011-01-05 14:32:29] johan...@php.net Automatic comment from SVN on behalf of johannes Revision: http://svn.php.net/viewvc/?view=revision&revision=307119 Log: Merge rev. 307095 - Fix bug #53632 with x87 fpu (scottmac) [2011-01-05 10:28:35] zdv2010 at gmail dot com I have this problem on PHP-5.2.14 on Windows XP SP3 C:\Documents and Settings\user>php -v PHP 5.2.14 (cli) (built: Jul 21 2010 18:43:55) Copyright (c) 1997-2010 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2010 Zend Technologies [2011-01-05 09:50:21] paj...@php.net Seems that the commit did not make it here: Fix: http://svn.php.net/viewvc?view=revision&revision=307095 Test case: http://svn.php.net/viewvc?view=revision&revision=307097 [2011-01-05 00:47:43] paj...@php.net My bad, forgot to revert a change in my previous attempt to fix this issue. Fresh co & build works, tests pass. 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=53632 -- Edit this bug report at http://bugs.php.net/bug.php?id=53632&edit=1
Req #53622 [Opn->Wfx]: CLI -w separate functions of striping whitespace and comments
Edit report at http://bugs.php.net/bug.php?id=53622&edit=1 ID: 53622 Updated by: ahar...@php.net Reported by:mnelson at teshy dot com Summary:CLI -w separate functions of striping whitespace and comments -Status: Open +Status: Wont fix Type: Feature/Change Request Package:CGI related Operating System: all PHP Version:5.3.4 Block user comment: N Private report: N New Comment: Won't fix, per discussion on IRC. As Johannes says, it's better left to third party tools. Previous Comments: [2011-01-04 17:50:39] johan...@php.net I didn't test the patch but two comments: The simple one is that the documentation in the man page is missing. The more complex one is around single line comments. T_COMMENT includes the trailing new line. So I assume that would become Such issues make me believe more and more in specialized tools like mentioned above :-) [2011-01-04 16:01:25] ahar...@php.net I tend to agree, but I implemented it anyway. :) Quick and dirty patch against trunk attached. [2011-01-04 16:01:20] ahar...@php.net The following patch has been added/updated: Patch Name: strip-comments-whitespace Revision: 1294153279 URL: http://bugs.php.net/patch-display.php?bug=53622&patch=strip-comments-whitespace&revision=1294153279 [2011-01-01 01:57:40] johan...@php.net I believe it is better to do this in userland. I'd actually drop the -w flag completely. Keeping the bug open so people can disagree and implement it :-) btw. a userspace beautifier is on http://pear.php.net/package/PHP_Beautifier [2010-12-28 17:44:55] mnelson at teshy dot com Description: It would be useful if The Command line option "-w" for stripping comments and whitespace was broken down into separate commands. One for striping whitespace and one for striping comments, the commands could be combined for users that want both. In our use case we have code that has become unreadable and needs excessive whitespace removed so it can be reformatted properly, we however want to keep all code comments. -- Edit this bug report at http://bugs.php.net/bug.php?id=53622&edit=1
Bug #53632 [Com]: PHP hangs on numeric value 2.2250738585072011e-308
Edit report at http://bugs.php.net/bug.php?id=53632&edit=1 ID: 53632 Comment by: tyra3l at gmail dot com Reported by:exploringbinary at gmail dot com Summary:PHP hangs on numeric value 2.2250738585072011e-308 Status: Closed Type: Bug Package:Math related PHP Version:5.3.4 Assigned To:scottmac Block user comment: N Private report: N New Comment: btw. 5.2 support officially ended. are there any chances that this bug will be fixed in 5.2, or this will be the first obstacle which will force the people out there to upgrade to 5.3? Tyrael Previous Comments: [2011-01-05 15:13:54] tyra3l at gmail dot com Just for the record, because some of my friends missed this: max_execution_time/set_time_limit cannot help you with this problem, because it's only gets checked between two userland instructions, hence this won't happen in this case. Tyrael [2011-01-05 14:35:27] johan...@php.net Automatic comment from SVN on behalf of johannes Revision: http://svn.php.net/viewvc/?view=revision&revision=307120 Log: Merge rev. 307097 Add test for bug #53632 (scottmac) [2011-01-05 14:32:29] johan...@php.net Automatic comment from SVN on behalf of johannes Revision: http://svn.php.net/viewvc/?view=revision&revision=307119 Log: Merge rev. 307095 - Fix bug #53632 with x87 fpu (scottmac) [2011-01-05 10:28:35] zdv2010 at gmail dot com I have this problem on PHP-5.2.14 on Windows XP SP3 C:\Documents and Settings\user>php -v PHP 5.2.14 (cli) (built: Jul 21 2010 18:43:55) Copyright (c) 1997-2010 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2010 Zend Technologies [2011-01-05 09:50:21] paj...@php.net Seems that the commit did not make it here: Fix: http://svn.php.net/viewvc?view=revision&revision=307095 Test case: http://svn.php.net/viewvc?view=revision&revision=307097 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=53632 -- Edit this bug report at http://bugs.php.net/bug.php?id=53632&edit=1
Bug #53632 [Com]: PHP hangs on numeric value 2.2250738585072011e-308
Edit report at http://bugs.php.net/bug.php?id=53632&edit=1 ID: 53632 Comment by: jannhorn at googlemail dot com Reported by:exploringbinary at gmail dot com Summary:PHP hangs on numeric value 2.2250738585072011e-308 Status: Closed Type: Bug Package:Math related PHP Version:5.3.4 Assigned To:scottmac Block user comment: N Private report: N New Comment: @Tyrael: Seems like it was already fixed for 5.2. http://svn.php.net/viewvc/php/php-src/branches/PHP_5_2/Zend/zend_strtod.c? view=log&pathrev=307095 Previous Comments: [2011-01-05 16:11:19] tyra3l at gmail dot com btw. 5.2 support officially ended. are there any chances that this bug will be fixed in 5.2, or this will be the first obstacle which will force the people out there to upgrade to 5.3? Tyrael [2011-01-05 15:13:54] tyra3l at gmail dot com Just for the record, because some of my friends missed this: max_execution_time/set_time_limit cannot help you with this problem, because it's only gets checked between two userland instructions, hence this won't happen in this case. Tyrael [2011-01-05 14:35:27] johan...@php.net Automatic comment from SVN on behalf of johannes Revision: http://svn.php.net/viewvc/?view=revision&revision=307120 Log: Merge rev. 307097 Add test for bug #53632 (scottmac) [2011-01-05 14:32:29] johan...@php.net Automatic comment from SVN on behalf of johannes Revision: http://svn.php.net/viewvc/?view=revision&revision=307119 Log: Merge rev. 307095 - Fix bug #53632 with x87 fpu (scottmac) [2011-01-05 10:28:35] zdv2010 at gmail dot com I have this problem on PHP-5.2.14 on Windows XP SP3 C:\Documents and Settings\user>php -v PHP 5.2.14 (cli) (built: Jul 21 2010 18:43:55) Copyright (c) 1997-2010 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2010 Zend Technologies 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=53632 -- Edit this bug report at http://bugs.php.net/bug.php?id=53632&edit=1
Bug #44287 [Fbk->Opn]: mysql_fetch_object calls __construct too late
Edit report at http://bugs.php.net/bug.php?id=44287&edit=1
ID: 44287
Updated by: u...@php.net
Reported by:jaap dot taal at gmail dot com
Summary:mysql_fetch_object calls __construct too late
-Status: Feedback
+Status: Open
Type: Bug
Package:MySQL related
Operating System: *
-PHP Version:5.2.5
+PHP Version:Any
Assigned To:mysql
Block user comment: N
Private report: N
New Comment:
Any version affected. Its questionable if we should change this and
break BC.
Previous Comments:
[2010-11-02 17:32:10] fel...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2008-11-10 01:00:06] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[2008-11-02 13:35:01] j...@php.net
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2008-03-25 13:30:23] jaap dot taal at gmail dot com
Note that moving the initialization of the id field from the constructor
to the declaration fixes this problem, i.e.:
class tbl_content {
var $id = null;
var $content;
function tbl_content() {
//$this->id = null;
}
}
However I still think that, from an object oriented perspective, the
constructor should be called first thing after creating an object. The
implementation of the mysql_fetch_object is wrong.
[2008-03-25 13:23:57] jaap dot taal at gmail dot com
The constructor of the object initializes the id variable to be null
(which is needed in other cases).
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=44287
--
Edit this bug report at http://bugs.php.net/bug.php?id=44287&edit=1
Bug #45921 [Fbk]: Can't initialize character set hebrew (path: C:\mysql\\share\charsets\)
Edit report at http://bugs.php.net/bug.php?id=45921&edit=1 ID: 45921 Updated by: and...@php.net Reported by:ymagriso at gmail dot com Summary:Can't initialize character set hebrew (path: C:\mysql\\share\charsets\) Status: Feedback Type: Bug Package:MySQLi related Operating System: win32 only PHP Version:5.2.6 Assigned To:mysql Block user comment: N Private report: N New Comment: Seems like libmysql issue. If still persists open a bug report at http://bugs.mysql.com Previous Comments: [2010-09-27 14:37:26] and...@php.net Automatic comment from SVN on behalf of andrey Revision: http://svn.php.net/viewvc/?view=revision&revision=303782 Log: Fixed bug #45921 (Can't initialize character set hebrew) sorry for committing it separated [2010-09-27 14:36:01] and...@php.net Automatic comment from SVN on behalf of andrey Revision: http://svn.php.net/viewvc/?view=revision&revision=303781 Log: Fixed bug #45921 (Can't initialize character set hebrew) [2010-08-05 15:38:40] johan...@php.net Please mind the last comments and test a more recent snapshot/release. [2009-04-27 11:54:05] johan...@php.net Sorry, my bad, confused names, SET_CHARSET_DIR is the one i meant, but that isn't exported, checking whether there's a reason or just oversight. [2009-04-27 11:25:58] johan...@php.net Please use $db->options(MYSQLI_SET_CHARSET_NAME, 'C:\\MySQL5.0\\share\\charsets'); to properly set the charset path. 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=45921 -- Edit this bug report at http://bugs.php.net/bug.php?id=45921&edit=1
Bug #45921 [Fbk->Bgs]: Can't initialize character set hebrew (path: C:\mysql\\share\charsets\)
Edit report at http://bugs.php.net/bug.php?id=45921&edit=1 ID: 45921 Updated by: and...@php.net Reported by:ymagriso at gmail dot com Summary:Can't initialize character set hebrew (path: C:\mysql\\share\charsets\) -Status: Feedback +Status: Bogus Type: Bug Package:MySQLi related Operating System: win32 only PHP Version:5.2.6 Assigned To:mysql Block user comment: N Private report: N New Comment: see previous comment Previous Comments: [2011-01-05 17:54:13] and...@php.net Seems like libmysql issue. If still persists open a bug report at http://bugs.mysql.com [2010-09-27 14:37:26] and...@php.net Automatic comment from SVN on behalf of andrey Revision: http://svn.php.net/viewvc/?view=revision&revision=303782 Log: Fixed bug #45921 (Can't initialize character set hebrew) sorry for committing it separated [2010-09-27 14:36:01] and...@php.net Automatic comment from SVN on behalf of andrey Revision: http://svn.php.net/viewvc/?view=revision&revision=303781 Log: Fixed bug #45921 (Can't initialize character set hebrew) [2010-08-05 15:38:40] johan...@php.net Please mind the last comments and test a more recent snapshot/release. [2009-04-27 11:54:05] johan...@php.net Sorry, my bad, confused names, SET_CHARSET_DIR is the one i meant, but that isn't exported, checking whether there's a reason or just oversight. 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=45921 -- Edit this bug report at http://bugs.php.net/bug.php?id=45921&edit=1
Bug #52861 [Com]: unset failes with ArrayObject and deep arrays
Edit report at http://bugs.php.net/bug.php?id=52861&edit=1
ID: 52861
Comment by: auke at muze dot nl
Reported by:mep_eisen at web dot de
Summary:unset failes with ArrayObject and deep arrays
Status: Open
Type: Bug
Package:SPL related
Operating System: Windows Vista 64
PHP Version:5.3.3
Block user comment: N
Private report: N
New Comment:
It's worse than this, ArrayObject gets confused on where to put the data
and mangles any containing object:
test script:
class IWouldLikeToPointOutABug {
}
$buggy = new IWouldLikeToPointOutABug();
$buggy->bug = new ArrayObject( );
$buggy->bug['foo']['bar'] = true;
echo "This looks normal\r\n";
var_dump( $buggy );
echo "This should be NULL\r\n";
var_dump( $buggy->thisIsNotHere );
Results in:
This looks normal
object(IWouldLikeToPointOutABug)#1 (1) {
["bug"]=>
object(ArrayObject)#2 (0) {
}
}
This should be NULL
array(1) {
["bar"]=>
bool(true)
}
Previous Comments:
[2010-09-16 17:23:11] mep_eisen at web dot de
Description:
Using deep arrays unset itself or ArrayObject misbehaves. It silently
does nothing.
The problem lies in iteration 3 that mixes ArrayObject and classic
arrays.
Test script:
---
echo "iteration1\n";
$arr = new ArrayObject();
$arr['foo'] = new ArrayObject();
$arr['foo']['bar'] = true;
unset($arr['foo']['bar']);
var_dump($arr);
echo "iteration2\n";
$arr = array();
$arr['foo']['bar'] = true;
unset($arr['foo']['bar']);
var_dump($arr);
echo "iteration3\n";
$arr = new ArrayObject();
$arr['foo']['bar'] = true;
unset($arr['foo']['bar']);
var_dump($arr);
Expected result:
iteration1
object(ArrayObject)#1 (1) {
["storage":"ArrayObject":private]=>
array(1) {
["foo"]=>
object(ArrayObject)#2 (1) {
["storage":"ArrayObject":private]=>
array(0) {
}
}
}
}
iteration2
array(1) {
["foo"]=>
array(0) {
}
}
iteration3
object(ArrayObject)#1 (1) {
["storage":"ArrayObject":private]=>
array(1) {
["foo"]=>
array(0) {
}
}
}
Actual result:
--
iteration1
object(ArrayObject)#1 (1) {
["storage":"ArrayObject":private]=>
array(1) {
["foo"]=>
object(ArrayObject)#2 (1) {
["storage":"ArrayObject":private]=>
array(0) {
}
}
}
}
iteration2
array(1) {
["foo"]=>
array(0) {
}
}
iteration3
object(ArrayObject)#1 (1) {
["storage":"ArrayObject":private]=>
array(1) {
["foo"]=>
array(1) {
["bar"]=>
bool(true)
}
}
}
--
Edit this bug report at http://bugs.php.net/bug.php?id=52861&edit=1
[PHP-BUG] Req #53656 [NEW]: extend Spl-class and override a methode
From:
Operating system:
PHP version: Irrelevant
Package: *General Issues
Bug Type: Feature/Change Request
Bug description:extend Spl-class and override a methode
Description:
Hi,
i would like to do something like that:
x = $x;
$this->y = $y;
}
public function splIntMethode($other, $operator) // override
SplInt-Methode
{
if($operator != '+')
throw new Exception();
if(!($other instanceof A))
throw new Exception();
return new A($x + $other->x, $y + $other->y);
}
}
$a0 = new A(1,2);
$a1 = new A(3,4); // $a1 is the '$other'-Objekt at methode
splIntMethode
$a2 = $a0 + $a1; // $operator +
?>
--
Edit bug report at http://bugs.php.net/bug.php?id=53656&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53656&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53656&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=53656&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53656&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=53656&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53656&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=53656&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=53656&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=53656&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=53656&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=53656&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=53656&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=53656&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=53656&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53656&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=53656&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=53656&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=53656&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=53656&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=53656&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=53656&r=mysqlcfg
Req #53594 [Com]: php-snmp rewrite
Edit report at http://bugs.php.net/bug.php?id=53594&edit=1 ID: 53594 Comment by: lytboris at gmail dot com Reported by:lytboris at gmail dot com Summary:php-snmp rewrite Status: Feedback Type: Feature/Change Request Package:SNMP related Operating System: irrelevant PHP Version:trunk Block user comment: N Private report: N New Comment: Introducing full-featured OO API. It covers bug #46065 also. Old API *_set_* functions actually sets `global' preferences, they are used when creating new object instance. $object->... properties are used object(session)-wise. Previous Comments: [2010-12-31 19:52:07] lytboris at gmail dot com OK. There will be full-featured OO API without adding new functions into legacy API (e.g. no session support). Though old functions will be provided with two features (in sake of code cimplicity): * multi-OID * strict output typing [2010-12-29 18:22:55] paj...@php.net No need to deprecate it, but tell anyone asking for a feature for the legacy API to migrate to the new shiny one :) [2010-12-29 18:21:57] paj...@php.net It is much easier and cleaner to simply go straight to OO then, without procedural API, and keep the old for legacy apps. [2010-12-29 18:17:11] lytboris at gmail dot com You have guessed my next target - OO interface. :-) If you apply new patch you'll see there is very small piece of code making SNMPv1 functions be polymorphic - dozen of lines, not more. My thoughts are that old API should be deprecated sometime, so there will be session-only support: both OO and non-OO. [2010-12-29 18:02:23] paj...@php.net What do you think about keeping the old APIs as it is, froze it and add a much nicer and flexible OO one instead? For any new improvements? That's what I did for zip and brings much more rooms for new stuff while reducing the maintenance work load. 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=53594 -- Edit this bug report at http://bugs.php.net/bug.php?id=53594&edit=1
Req #53655 [Opn->Asn]: Improve speed of DOMNode::C14N() on large XML documents
Edit report at http://bugs.php.net/bug.php?id=53655&edit=1
ID: 53655
Updated by: rricha...@php.net
Reported by:olav dot morken at uninett dot no
Summary:Improve speed of DOMNode::C14N() on large XML
documents
-Status: Open
+Status: Assigned
Type: Feature/Change Request
Package:DOM XML related
PHP Version:5.3.4
-Assigned To:
+Assigned To:rrichards
Block user comment: N
Private report: N
Previous Comments:
[2011-01-05 08:33:02] olav dot morken at uninett dot no
Description:
The C14N() function appears to have a runtime that is O(N^2) (or
possibly worse?) depending on input size, which means that it becomes
very slow as the input grows. For example, an input with around 196000
nodes takes about 290 seconds, while an input with 486000 nodes takes
2200 seconds.
Note that this problem only occurs when canonicalizing a subtree of the
docuemnt. If we canonicalize the whole document, it completes almost
immediately.
The problem is that canonicalization uses an XPath expression to find
the nodeset that should be canonicalized. Evaluation of the XPath
expression takes a lot of time as the input size grows, but the libxml2
xmlC14NDocSaveTo() function also has to do a lookup in the nodeset
returned by the XPath expression for every node it encounters.
I believe a better solution would be to do this like it is done in the
xmlsec library. This library use the xmlC14NExecute()-function instead,
which accepts a callback that determines whether a node should be
included in the result. This should make the speed of canonicalization
linear with the input size.
Test script:
---
load('some-large-xml-file.xml');
$start = microtime(TRUE);
$doc->documentElement->C14N(FALSE, FALSE);
echo "Done in " . (microtime(TRUE) - $start) . " seconds.\n";
--
Edit this bug report at http://bugs.php.net/bug.php?id=53655&edit=1
[PHP-BUG] Req #53657 [NEW]: Make at least PDOStatement::bindValue and PDOStatement::bindParam() chainable!
From:
Operating system: any
PHP version: 5.3.4
Package: *Database Functions
Bug Type: Feature/Change Request
Bug description:Make at least PDOStatement::bindValue and
PDOStatement::bindParam() chainable!
Description:
---
>From manual page: http://www.php.net/pdostatement.bindvalue
---
The PDOStatement::bindValue and PDOStatement::bindParam methods should be
chainable. Look at my test script below for an example.
Test script:
---
// create a new PDO
$dbh = new PDO($dsn, $user, $pass);
// the example SQL statement
$sql = "INSERT INTO db.table (id, firstName, lastName) VALUES(NULL,
:firstName, :lastName)";
$statement = $dbh->prepare($sql);
// current behaviour
$statement->bindValue(':firstName', 'Foo');
$statement->bindValue(':lastName', 'Bar');
// and so on...
$statement->execute();
// what I wish for and what saves a lot of copy & paste, but especially
time
$statement->bindValue(':firstName', 'Foo')
->bindValue(':lastName', 'Bar');
->execute();
--
Edit bug report at http://bugs.php.net/bug.php?id=53657&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53657&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53657&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=53657&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53657&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=53657&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53657&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=53657&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=53657&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=53657&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=53657&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=53657&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=53657&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=53657&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=53657&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53657&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=53657&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=53657&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=53657&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=53657&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=53657&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=53657&r=mysqlcfg
Bug #53632 [Com]: PHP hangs on numeric value 2.2250738585072011e-308
Edit report at http://bugs.php.net/bug.php?id=53632&edit=1 ID: 53632 Comment by: xpipe at hotmail dot de Reported by:exploringbinary at gmail dot com Summary:PHP hangs on numeric value 2.2250738585072011e-308 Status: Closed Type: Bug Package:Math related PHP Version:5.3.4 Assigned To:scottmac Block user comment: N Private report: N New Comment: Considering the official Windows binaries are affected by this, will there be new binaries or a new PHP version released to reflect this issue? I'm asking because it is possible to take down vulnerable PHP apps by this as easily as finding a request variable that is actually accessed. Requesting viewtopic.php?f=2.2250738585072011e-308 for phpBB or index.php?q=2.2250738585072011e-308 for Drupal is enough to freeze the PHP installation if it is affected. Previous Comments: [2011-01-05 16:27:52] jannhorn at googlemail dot com @Tyrael: Seems like it was already fixed for 5.2. http://svn.php.net/viewvc/php/php-src/branches/PHP_5_2/Zend/zend_strtod.c? view=log&pathrev=307095 [2011-01-05 16:11:19] tyra3l at gmail dot com btw. 5.2 support officially ended. are there any chances that this bug will be fixed in 5.2, or this will be the first obstacle which will force the people out there to upgrade to 5.3? Tyrael [2011-01-05 15:13:54] tyra3l at gmail dot com Just for the record, because some of my friends missed this: max_execution_time/set_time_limit cannot help you with this problem, because it's only gets checked between two userland instructions, hence this won't happen in this case. Tyrael [2011-01-05 14:35:27] johan...@php.net Automatic comment from SVN on behalf of johannes Revision: http://svn.php.net/viewvc/?view=revision&revision=307120 Log: Merge rev. 307097 Add test for bug #53632 (scottmac) [2011-01-05 14:32:29] johan...@php.net Automatic comment from SVN on behalf of johannes Revision: http://svn.php.net/viewvc/?view=revision&revision=307119 Log: Merge rev. 307095 - Fix bug #53632 with x87 fpu (scottmac) 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=53632 -- Edit this bug report at http://bugs.php.net/bug.php?id=53632&edit=1
Bug #53632 [Csd]: PHP hangs on numeric value 2.2250738585072011e-308
Edit report at http://bugs.php.net/bug.php?id=53632&edit=1 ID: 53632 Updated by: paj...@php.net Reported by:exploringbinary at gmail dot com Summary:PHP hangs on numeric value 2.2250738585072011e-308 Status: Closed Type: Bug Package:Math related PHP Version:5.3.4 Assigned To:scottmac Block user comment: N Private report: N New Comment: @ cswarth at gmail dot com Thanks for all the feedbacks, we had enough info and details to fix the issue and new releases will be done shortly. Previous Comments: [2011-01-05 19:39:09] xpipe at hotmail dot de Considering the official Windows binaries are affected by this, will there be new binaries or a new PHP version released to reflect this issue? I'm asking because it is possible to take down vulnerable PHP apps by this as easily as finding a request variable that is actually accessed. Requesting viewtopic.php?f=2.2250738585072011e-308 for phpBB or index.php?q=2.2250738585072011e-308 for Drupal is enough to freeze the PHP installation if it is affected. [2011-01-05 16:27:52] jannhorn at googlemail dot com @Tyrael: Seems like it was already fixed for 5.2. http://svn.php.net/viewvc/php/php-src/branches/PHP_5_2/Zend/zend_strtod.c? view=log&pathrev=307095 [2011-01-05 16:11:19] tyra3l at gmail dot com btw. 5.2 support officially ended. are there any chances that this bug will be fixed in 5.2, or this will be the first obstacle which will force the people out there to upgrade to 5.3? Tyrael [2011-01-05 15:13:54] tyra3l at gmail dot com Just for the record, because some of my friends missed this: max_execution_time/set_time_limit cannot help you with this problem, because it's only gets checked between two userland instructions, hence this won't happen in this case. Tyrael [2011-01-05 14:35:27] johan...@php.net Automatic comment from SVN on behalf of johannes Revision: http://svn.php.net/viewvc/?view=revision&revision=307120 Log: Merge rev. 307097 Add test for bug #53632 (scottmac) 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=53632 -- Edit this bug report at http://bugs.php.net/bug.php?id=53632&edit=1
Bug #53503 [Com]: mysqli::query returns false after successful LOAD DATA query
Edit report at http://bugs.php.net/bug.php?id=53503&edit=1
ID: 53503
Comment by: jeremy dot archuleta at gmail dot com
Reported by:clewis at myfonts dot com
Summary:mysqli::query returns false after successful LOAD
DATA query
Status: Closed
Type: Bug
Package:MySQLi related
Operating System: Linux - CentOS
PHP Version:5.3.3
Assigned To:kalle
Block user comment: N
Private report: N
New Comment:
This also occurs in the "mysql" package. The bug report I filed
yesterday (before
I saw this) is here: http://bugs.php.net/bug.php?id=53649
Previous Comments:
[2010-12-12 17:18:22] ka...@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.
The fix will be included in PHP 5.3.5
[2010-12-12 17:17:53] ka...@php.net
Automatic comment from SVN on behalf of kalle
Revision: http://svn.php.net/viewvc/?view=revision&revision=306266
Log: Fixed bug #53503 (mysqli::query returns false after successful LOAD
DATA query)
[2010-12-09 01:16:44] clewis at myfonts dot com
Description:
When a LOAD DATA LOCAL INFILE query is run after a previous SELECT query
on the
same mysqli handle, mysqli::query returns false even though the LOAD
DATA query
is successful.
Additionally, PHP outputs two warnings during the mysqli::query call:
PHP Warning: mysqli::query(): (0/0): in /path/to/script.php on
line 16
Warning: mysqli::query(): (0/0): in /path/to/script.php on line 16
Properties of the mysqli object, such as errorno and affected_rows,
indicate
success.
If the LOAD DATA query is the first query run on a particular mysqli
object, it
works fine.
We are using the mysqlnd lib.
Configuration:
./configure --prefix=/usr/local --with-xmlrpc --with-apxs2 --with-
mysqli=mysqlnd --with-pdo-mysql=mysqlnd --with-curl --with-curlwrappers
--
enable-bcmath --with-gd=/usr --with-mcrypt=/usr/local --enable-mbstring
--with-
zlib --with-iconv --enable-soap --enable-ftp --without-sqlite --with-xsl
--
enable-pcntl --enable-sockets --with-openssl
This may be the same as inactive Bug #47387.
Test script:
---
$db = new mysqli($host,$user,$pass,$dbname);
$tempfile = tempnam("/tmp","loaddata_");
file_put_contents($tempfile, "1");
$db->query("create table if not exists LoadDataTest (Column1 int
unsigned not null primary key)");
$db->query("select * from LoadDataTest limit 1"); //LOAD DATA works
properly without this
$result = $db->query("load data local infile '$tempfile' replace into
table LoadDataTest (Column1)");
if ($result) print "Load data success.\n";
else print "Error {$db->errno}: {$db->error}\n";
unlink($tempfile);
Expected result:
mysqli::query returns result object
Actual result:
--
mysqli::query returns false
--
Edit this bug report at http://bugs.php.net/bug.php?id=53503&edit=1
Bug #53649 [Opn]: mysql_query with "load data" unable to save result set
Edit report at http://bugs.php.net/bug.php?id=53649&edit=1
ID: 53649
User updated by:jeremy dot archuleta at gmail dot com
Reported by:jeremy dot archuleta at gmail dot com
Summary:mysql_query with "load data" unable to save result
set
Status: Open
Type: Bug
Package:MySQL related
Operating System: Mac OS
PHP Version:5.3.4
Block user comment: N
Private report: N
New Comment:
Bug is also reported in MySQLi package:
http://bugs.php.net/bug.php?id=53503
And reported to be fixed in PHP 5.3.5
Previous Comments:
[2011-01-04 16:24:03] jeremy dot archuleta at gmail dot com
Description:
I believe that using mysql_query() with "load data" should always be a
TRUE/FALSE return value. However, if a mysql_query() call that returns a
result
set is performed *before* the "load data" query, then there is a warning
stating
that the result set can not be saved.
In short:
Warning:
mysql_query("SELECT ..."); // result set *before*
mysql_query("LOAD DATA ..."); // warning
Works:
mysql_query("LOAD DATA ..."); // works
mysql_query("SELECT ..."); // result set *after*
Works:
mysql_query("UPDATE ..."); // *no* result set
mysql_query("LOAD DATA ..."); // works
Works and Warning:
mysql_query("LOAD DATA ..."); // works
mysql_query("SELECT ..."); // result set *after*
mysql_query("LOAD DATA ..."); // warning
MacOS 10.5.8
$ uname -a
Darwin clark-kent-2.local 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15
16:55:01
PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386 i386
Using PHP from macports
$ php --version
PHP 5.3.3 (cli) (built: Oct 25 2010 17:21:53)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
$ php -i
phpinfo()
PHP Version => 5.3.3
System => Darwin clark-kent-2.local 9.8.0 Darwin Kernel Version 9.8.0:
Wed Jul
15 16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386 i386
Build Date => Oct 25 2010 17:19:57
Configure Command => './configure' '--prefix=/opt/local' '--
mandir=/opt/local/share/man' '--infodir=/opt/local/share/info'
'--with-config-
file-path=/opt/local/etc/php5' '--with-config-file-scan-
dir=/opt/local/var/db/php5' '--disable-all' '--enable-bcmath'
'--enable-ctype'
'--enable-dom' '--enable-fileinfo' '--enable-filter' '--enable-hash'
'--enable-
json' '--enable-libxml' '--enable-pdo' '--enable-phar'
'--enable-session' '--
enable-simplexml' '--enable-tokenizer' '--enable-xml'
'--enable-xmlreader' '--
enable-xmlwriter' '--with-bz2=/opt/local' '--with-mhash=/opt/local'
'--with-
pcre-regex=/opt/local' '--with-readline=/opt/local' '--with-libxml-
dir=/opt/local' '--with-zlib=/opt/local' '--disable-cgi' '--with-
apxs2=/opt/local/apache2/bin/apxs' '--with-pear=/opt/local/lib/php'
Using MySQL from macports
$ mysql --version
mysql Ver 14.14 Distrib 5.1.51, for apple-darwin9.8.0 (i386) using
readline 6.1
Test script:
---
Expected result:
This works
This also works
This fails with warning
Actual result:
--
This works
This also works
This fails with warning
Warning: mysql_query(): Unable to save result set in tmp.php on line 18
--
Edit this bug report at http://bugs.php.net/bug.php?id=53649&edit=1
Bug #51146 [Com]: mcrypt doesn't do OFB mode correctly
Edit report at http://bugs.php.net/bug.php?id=51146&edit=1
ID: 51146
Comment by: me at haravikk dot com
Reported by:zelnaga at gmail dot com
Summary:mcrypt doesn't do OFB mode correctly
Status: Open
Type: Bug
Package:mcrypt related
Operating System: Windows XP
PHP Version:5.3.1
Block user comment: N
Private report: N
New Comment:
To answer your first question, performing the encryption per-byte is
kind of odd, I haven't done much
testing but I don't think it actually consumes the entire input vector,
only the first byte, just think of
it as running with an 8-bit wide state, rather than the more typical
128-bit wide state.
I've never had the time to confirm that this is the exact case, though,
but I believe it's compatible with
other cryptography solutions that can operate per-byte.
For your second point; sorry I should have pointed out that there is no
predefined constant for
MCRYPT_MODE_NCFB, you can however just enter it manually as 'ncfb' like
so:
mcrypt_module_open('rijndael-128', '', 'ncfb', '');
So if there's a failing on the PHP side it's that we need an
MCRYPT_MODE_NCFB, and that MCRYPT_MODE_CFB
and MCRYPT_MODE_OFB should be properly documented so people don't keep
using them expecting different
results!
Previous Comments:
[2010-06-19 15:42:52] zelnaga at gmail dot com
Also, there's still the matter of CFB. So NOFB is what most everything
else refers to as OFB but CFB'a wrong, as well, and it has no NCFB
counter part.
[2010-06-19 15:40:10] zelnaga at gmail dot com
What does it even mean to do OFB at the byte-level? Per
, in OFB, you
encrypt the IV with the key with the chosen block cipher algorithm and
then XOR that against the plaintext to get the ciphertext. How do you
do that at the "byte level"? Do you do substrings or something?
[2010-06-01 12:22:07] me at haravikk dot com
You're using the wrong OFB mode, you need to use MCRYPT_MODE_NOFB.
MCRYPT_MODE_OFB is per-byte, while MCRYPT_MODE_NOFB is per-block and
gives the
result you were expecting.
[2010-04-13 23:36:44] zelnaga at gmail dot com
I was comparing mcrypt against openssl_encrypt() and... well, either
OpenSSL is wrong or mcrypt is wrong:
ie. mcrypt, in CTR, CBC and ECB modes equal OpenSSL in OFB and CFB modes
but not mcrypt in OFB and CFB modes. In other words, OpenSSL's OFB !=
mcrypt's OFB and they should.
[2010-02-26 16:16:56] zelnaga at gmail dot com
As far as I know, the IV is also used for the first round, so I am not
sure if your statement holds up.
Ummm... the IV - as defined in mcrypt_generic_init - is only used in
the first round. Per wikipedia, the first block against which the
plaintext is XOR'd is the IV encrypted with the key. That's true in
both CFB and OFB modes of operation. The difference between CFB and OFB
is what subsequent blocks encrypt for the keystream. So, per that, the
first block should be the same. And as for my first bug report...
All of those should produce the same ciphertext. As it stands, only
ecb, cbc and ctr produce the same ciphertext. ofb and cfb produce the
same thing as each other (and, for the first block, they should, as I
already mentioned), however, they're not producing the same thing as any
of the other modes when, in fact, they should be.
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=51146
--
Edit this bug report at http://bugs.php.net/bug.php?id=51146&edit=1
[PHP-BUG] Bug #53658 [NEW]: is_writable returns always false
From:
Operating system: Linux 2.6.35
PHP version: 5.3SVN-2011-01-05 (SVN)
Package: Filesystem function related
Bug Type: Bug
Bug description:is_writable returns always false
Description:
When php script is run via apache is_writable always returns false :
'is_writable()' always returns 'false' whatever :
- the permission write sets or not.
- safe_mode on or off
- the owner of the file being root:root or apache:apache
on the other side, 'is_readable()' returns the correct value (either 'true'
when the file is made readable or 'false' when the file is made
unreadable).
But, when the same script is run by the php command line (under root) -
is_writable returns the correct value.
Test script:
---
";
} else {
echo "is not writable!!!";
}
?>
Expected result:
is_writable in case 'toto' is writable
is not writable in case 'toto' is not writable
--
Edit bug report at http://bugs.php.net/bug.php?id=53658&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53658&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53658&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=53658&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53658&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=53658&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53658&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=53658&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=53658&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=53658&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=53658&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=53658&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=53658&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=53658&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=53658&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53658&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=53658&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=53658&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=53658&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=53658&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=53658&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=53658&r=mysqlcfg
[PHP-BUG] Req #53659 [NEW]: Implementing RegexIterator::getRegex() method
From:
Operating system: All
PHP version: 5.3SVN-2011-01-05 (SVN)
Package: SPL related
Bug Type: Feature/Change Request
Bug description:Implementing RegexIterator::getRegex() method
Description:
I'd like to see an getRegex() method in the regexIterator class that will
return the regular expression that is initialized during its __construct().
Currently there is no way of retrieving that information except for saving
it yourself outside the object or extending regexiterator in order to save
the regex inside a custom constructor.
It would be nice if the information about the object could actually be
retrieved natively since this data is already present, just not visible to
the outside world.
Attached is a patch with an implementation.
Test script:
---
$array = array('cat', 'hat', 'sat');
$iterator = new ArrayIterator($array);
$regexIterator = new RegexIterator($iterator, '/.at/');
var_dump($regexIterator->getRegex());
Expected result:
string(5) "/.at/"
Actual result:
--
PHP Fatal error: Call to undefined method ArrayIterator::getRegex()
--
Edit bug report at http://bugs.php.net/bug.php?id=53659&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53659&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53659&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=53659&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53659&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=53659&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53659&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=53659&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=53659&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=53659&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=53659&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=53659&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=53659&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=53659&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=53659&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53659&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=53659&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=53659&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=53659&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=53659&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=53659&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=53659&r=mysqlcfg
Bug #53658 [Opn->Fbk]: is_writable returns always false
Edit report at http://bugs.php.net/bug.php?id=53658&edit=1
ID: 53658
Updated by: ras...@php.net
Reported by:pierregobin at free dot fr
Summary:is_writable returns always false
-Status: Open
+Status: Feedback
Type: Bug
Package:Filesystem function related
Operating System: Linux 2.6.35
PHP Version:5.3SVN-2011-01-05 (SVN)
Block user comment: N
Private report: N
New Comment:
Are you absolutely sure your web server is running as user apache? Do a
"ps -aux
| grep httpd" or "ps aux | grep apache" and see which user it is running
as.
is_writable works fine everywhere as far as I know.
Previous Comments:
[2011-01-05 22:38:05] pierregobin at free dot fr
Description:
When php script is run via apache is_writable always returns false :
'is_writable()' always returns 'false' whatever :
- the permission write sets or not.
- safe_mode on or off
- the owner of the file being root:root or apache:apache
on the other side, 'is_readable()' returns the correct value (either
'true' when the file is made readable or 'false' when the file is made
unreadable).
But, when the same script is run by the php command line (under root) -
is_writable returns the correct value.
Test script:
---
";
} else {
echo "is not writable!!!";
}
?>
Expected result:
is_writable in case 'toto' is writable
is not writable in case 'toto' is not writable
--
Edit this bug report at http://bugs.php.net/bug.php?id=53658&edit=1
[PHP-BUG] Bug #53661 [NEW]: imagepstext fails for all values of AA steps not just non 4 or 16
From: Operating system: Redhat Linux PHP version: 5.3.4 Package: GD related Bug Type: Bug Bug description:imagepstext fails for all values of AA steps not just non 4 or 16 Description: Reports Warning: imagepstext(): AA steps must be 4 or 16 even if 4 or 16 is specified Test script: --- $font_file = "font.pfm"; $im = imagecreatetruecolor(200, 200); $black = imagecolorallocate($im, 0, 0, 0); $white = imagecolorallocate($im, 255, 255, 255); $font = imagepsloadfont( $font_file ); $coords = imagepstext($im, 'Sample text is simple', $font, 12, $black, $white, 50, 50, 0, 0, 0.0, 4); print_r( $coords ); Expected result: should return a array of 4 values Actual result: -- returns NULL and always generates Warning: imagepstext(): AA steps must be 4 or 16 even if AA steps parameter is defaulted or explicit 4 or 16 works correctly on 5.3.3 and 5.2.16 -- Edit bug report at http://bugs.php.net/bug.php?id=53661&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=53661&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=53661&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=53661&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=53661&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=53661&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=53661&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=53661&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=53661&r=needscript Try newer version: http://bugs.php.net/fix.php?id=53661&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=53661&r=support Expected behavior: http://bugs.php.net/fix.php?id=53661&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=53661&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=53661&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=53661&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53661&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=53661&r=dst IIS Stability: http://bugs.php.net/fix.php?id=53661&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=53661&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=53661&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=53661&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=53661&r=mysqlcfg
Req #53466 [Opn->Csd]: sqlite3 columnType() returns SQLITE3_NULL when not in fetch loop
Edit report at http://bugs.php.net/bug.php?id=53466&edit=1
ID: 53466
Updated by: scott...@php.net
Reported by:danielc at analysisandsolutions dot com
Summary:sqlite3 columnType() returns SQLITE3_NULL when not
in fetch loop
-Status: Open
+Status: Closed
Type: Feature/Change Request
Package:SQLite related
Operating System: linux
PHP Version:5.3SVN-2010-12-03 (SVN)
-Assigned To:
+Assigned To:scottmac
Block user comment: N
Private report: N
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:
[2011-01-06 01:09:01] scott...@php.net
Automatic comment from SVN on behalf of scottmac
Revision: http://svn.php.net/viewvc/?view=revision&revision=307143
Log: Implemented FR #53466 (SQLite3Result::columnType() should return
false after all of the rows have been fetched).
[2010-12-03 18:28:15] danielc at analysisandsolutions dot com
Description:
The SQLite3Result::columnType() method returns SQLITE3_NULL (5) if not
looping over results. This is done because the data type is unknown.
But this leads to confusion, because SQLITE3_NULL is a legitimate answer
in some cases when inside the loop. It would be clearer if PHP returned
NULL or FALSE instead.
Test script:
---
$db = new SQLite3(':memory:');
$db->exec('CREATE TABLE test (whatever INTEGER)');
$db->exec('INSERT INTO test (whatever) VALUES (1)');
$result = $db->query('SELECT * FROM test');
while ($row = $result->fetchArray(SQLITE3_NUM)) {
var_dump($result->columnType(0)); // int(1) [SQLITE3_INTEGER]
}
// Seems returning null or false is more appropriate.
var_dump($result->columnType(0)); // int(5) [SQLITE3_NULL]
$result->finalize();
$db->close();
echo "Done\n";
Expected result:
int(1)
bool(false)
Done
Actual result:
--
int(1)
int(5)
Done
--
Edit this bug report at http://bugs.php.net/bug.php?id=53466&edit=1
Bug #53336 [Com]: queries on create_function return only one result
Edit report at http://bugs.php.net/bug.php?id=53336&edit=1
ID: 53336
Comment by: scott...@php.net
Reported by:cbruner at quadro dot net
Summary:queries on create_function return only one result
Status: Open
Type: Bug
Package:SQLite related
Operating System: linux
PHP Version:5.3.3
Block user comment: N
Private report: N
New Comment:
Can you give me a full test script, I'll need data too to track this
down.
Previous Comments:
[2010-11-18 06:19:33] cbruner at quadro dot net
Description:
Using sqlite3, create a function to do a comparison
(SQLite3::createFunction)
Then query a table using the function.
Only one result is returned when multiple results would be expected.
Test script:
---
// callback function for use by the sqlite3 class which returns the
distance between 2 points on the earth
function SqLDistance($Latitude,$Longitude,$Lat,$Long)
{
$result = 1.0; // flag to be off the earth!
if (isset($Latitude) && isset($Longitude))
{
$lat1rad = $Latitude * 0.01745327;// degrees * pi over
180
$lat2rad = $Lat * 0.01745327;// degrees * pi over 180
$long1rad = $Longitude * 0.01745327;// degrees * pi
over 180
$long2rad = $Long * 0.01745327;// degrees * pi over
180
// apply the spherical law of cosines to our
$earthRadius = 6378.1; //km
$result = $earthRadius *
acos(sin($lat1rad) * sin($lat2rad) +
cos($lat1rad) * cos($lat2rad) * cos($long2rad - $long1rad));
}
return $result;
}
class MyDB extends SQLite3
{
function __construct()
{
$this->open('zipcode.db');
$this->createFunction('Distance','SqlDistance',4);
}
function Borked($lat,$long,$count)
{
$result = $this->query("Select *,Distance(Lat,Long,$lat,$long)
as Distance from agents order by Distance Limit 0,$count");
return $result->fetchArray();
}
}
Expected result:
An array of results with a length greater then 1.
Actual result:
--
An array of result.
--
Edit this bug report at http://bugs.php.net/bug.php?id=53336&edit=1
Bug #53336 [Opn->Bgs]: queries on create_function return only one result
Edit report at http://bugs.php.net/bug.php?id=53336&edit=1
ID: 53336
Updated by: scott...@php.net
Reported by:cbruner at quadro dot net
Summary:queries on create_function return only one result
-Status: Open
+Status: Bogus
Type: Bug
Package:SQLite related
Operating System: linux
PHP Version:5.3.3
Block user comment: N
Private report: N
New Comment:
Actually you only return one row. fetchArray() only fetches the first
result since
SQLite isn't buffered.
You need to loop and call fetchArray() multiple times.
Previous Comments:
[2011-01-06 01:13:38] scott...@php.net
Can you give me a full test script, I'll need data too to track this
down.
[2010-11-18 06:19:33] cbruner at quadro dot net
Description:
Using sqlite3, create a function to do a comparison
(SQLite3::createFunction)
Then query a table using the function.
Only one result is returned when multiple results would be expected.
Test script:
---
// callback function for use by the sqlite3 class which returns the
distance between 2 points on the earth
function SqLDistance($Latitude,$Longitude,$Lat,$Long)
{
$result = 1.0; // flag to be off the earth!
if (isset($Latitude) && isset($Longitude))
{
$lat1rad = $Latitude * 0.01745327;// degrees * pi over
180
$lat2rad = $Lat * 0.01745327;// degrees * pi over 180
$long1rad = $Longitude * 0.01745327;// degrees * pi
over 180
$long2rad = $Long * 0.01745327;// degrees * pi over
180
// apply the spherical law of cosines to our
$earthRadius = 6378.1; //km
$result = $earthRadius *
acos(sin($lat1rad) * sin($lat2rad) +
cos($lat1rad) * cos($lat2rad) * cos($long2rad - $long1rad));
}
return $result;
}
class MyDB extends SQLite3
{
function __construct()
{
$this->open('zipcode.db');
$this->createFunction('Distance','SqlDistance',4);
}
function Borked($lat,$long,$count)
{
$result = $this->query("Select *,Distance(Lat,Long,$lat,$long)
as Distance from agents order by Distance Limit 0,$count");
return $result->fetchArray();
}
}
Expected result:
An array of results with a length greater then 1.
Actual result:
--
An array of result.
--
Edit this bug report at http://bugs.php.net/bug.php?id=53336&edit=1
Bug #53336 [Bgs]: queries on create_function return only one result
Edit report at http://bugs.php.net/bug.php?id=53336&edit=1
ID: 53336
User updated by:cbruner at quadro dot net
Reported by:cbruner at quadro dot net
Summary:queries on create_function return only one result
Status: Bogus
Type: Bug
Package:SQLite related
Operating System: linux
PHP Version:5.3.3
Block user comment: N
Private report: N
New Comment:
This bug is a month old for me now, and I can't remember if I tried
fetcharray or
not.
Let's mark it bogus and leave it at that.
Previous Comments:
[2011-01-06 01:18:09] scott...@php.net
Actually you only return one row. fetchArray() only fetches the first
result since
SQLite isn't buffered.
You need to loop and call fetchArray() multiple times.
[2011-01-06 01:13:38] scott...@php.net
Can you give me a full test script, I'll need data too to track this
down.
[2010-11-18 06:19:33] cbruner at quadro dot net
Description:
Using sqlite3, create a function to do a comparison
(SQLite3::createFunction)
Then query a table using the function.
Only one result is returned when multiple results would be expected.
Test script:
---
// callback function for use by the sqlite3 class which returns the
distance between 2 points on the earth
function SqLDistance($Latitude,$Longitude,$Lat,$Long)
{
$result = 1.0; // flag to be off the earth!
if (isset($Latitude) && isset($Longitude))
{
$lat1rad = $Latitude * 0.01745327;// degrees * pi over
180
$lat2rad = $Lat * 0.01745327;// degrees * pi over 180
$long1rad = $Longitude * 0.01745327;// degrees * pi
over 180
$long2rad = $Long * 0.01745327;// degrees * pi over
180
// apply the spherical law of cosines to our
$earthRadius = 6378.1; //km
$result = $earthRadius *
acos(sin($lat1rad) * sin($lat2rad) +
cos($lat1rad) * cos($lat2rad) * cos($long2rad - $long1rad));
}
return $result;
}
class MyDB extends SQLite3
{
function __construct()
{
$this->open('zipcode.db');
$this->createFunction('Distance','SqlDistance',4);
}
function Borked($lat,$long,$count)
{
$result = $this->query("Select *,Distance(Lat,Long,$lat,$long)
as Distance from agents order by Distance Limit 0,$count");
return $result->fetchArray();
}
}
Expected result:
An array of results with a length greater then 1.
Actual result:
--
An array of result.
--
Edit this bug report at http://bugs.php.net/bug.php?id=53336&edit=1
Bug #53661 [Opn]: imagepstext fails for all values of AA steps not just non 4 or 16
Edit report at http://bugs.php.net/bug.php?id=53661&edit=1 ID: 53661 User updated by:scott at gifttree dot com Reported by:scott at gifttree dot com Summary:imagepstext fails for all values of AA steps not just non 4 or 16 Status: Open Type: Bug Package:GD related Operating System: Redhat Linux PHP Version:5.3.4 Block user comment: N Private report: N New Comment: Snapshot php5.3-201101052330 appears to work correctly Previous Comments: [2011-01-06 00:38:47] scott at gifttree dot com Description: Reports Warning: imagepstext(): AA steps must be 4 or 16 even if 4 or 16 is specified Test script: --- $font_file = "font.pfm"; $im = imagecreatetruecolor(200, 200); $black = imagecolorallocate($im, 0, 0, 0); $white = imagecolorallocate($im, 255, 255, 255); $font = imagepsloadfont( $font_file ); $coords = imagepstext($im, 'Sample text is simple', $font, 12, $black, $white, 50, 50, 0, 0, 0.0, 4); print_r( $coords ); Expected result: should return a array of 4 values Actual result: -- returns NULL and always generates Warning: imagepstext(): AA steps must be 4 or 16 even if AA steps parameter is defaulted or explicit 4 or 16 works correctly on 5.3.3 and 5.2.16 -- Edit this bug report at http://bugs.php.net/bug.php?id=53661&edit=1
Bug #53632 [Com]: PHP hangs on numeric value 2.2250738585072011e-308
Edit report at http://bugs.php.net/bug.php?id=53632&edit=1 ID: 53632 Comment by: lukemoynihan at gmail dot com Reported by:exploringbinary at gmail dot com Summary:PHP hangs on numeric value 2.2250738585072011e-308 Status: Closed Type: Bug Package:Math related PHP Version:5.3.4 Assigned To:scottmac Block user comment: N Private report: N New Comment: As a workaround until I can patch php I have used the following pure php solution: http://stackoverflow.com/questions/4610651/any-problems-with-the-following-work- around-for-php-bug-53632 Previous Comments: [2011-01-05 19:43:21] paj...@php.net @ cswarth at gmail dot com Thanks for all the feedbacks, we had enough info and details to fix the issue and new releases will be done shortly. [2011-01-05 19:39:09] xpipe at hotmail dot de Considering the official Windows binaries are affected by this, will there be new binaries or a new PHP version released to reflect this issue? I'm asking because it is possible to take down vulnerable PHP apps by this as easily as finding a request variable that is actually accessed. Requesting viewtopic.php?f=2.2250738585072011e-308 for phpBB or index.php?q=2.2250738585072011e-308 for Drupal is enough to freeze the PHP installation if it is affected. [2011-01-05 16:27:52] jannhorn at googlemail dot com @Tyrael: Seems like it was already fixed for 5.2. http://svn.php.net/viewvc/php/php-src/branches/PHP_5_2/Zend/zend_strtod.c? view=log&pathrev=307095 [2011-01-05 16:11:19] tyra3l at gmail dot com btw. 5.2 support officially ended. are there any chances that this bug will be fixed in 5.2, or this will be the first obstacle which will force the people out there to upgrade to 5.3? Tyrael [2011-01-05 15:13:54] tyra3l at gmail dot com Just for the record, because some of my friends missed this: max_execution_time/set_time_limit cannot help you with this problem, because it's only gets checked between two userland instructions, hence this won't happen in this case. Tyrael 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=53632 -- Edit this bug report at http://bugs.php.net/bug.php?id=53632&edit=1
Bug #53632 [Com]: PHP hangs on numeric value 2.2250738585072011e-308
Edit report at http://bugs.php.net/bug.php?id=53632&edit=1 ID: 53632 Comment by: liaogz82 at singnet dot com dot sg Reported by:exploringbinary at gmail dot com Summary:PHP hangs on numeric value 2.2250738585072011e-308 Status: Closed Type: Bug Package:Math related PHP Version:5.3.4 Assigned To:scottmac Block user comment: N Private report: N New Comment: hang on mine. 32 bit gangzh...@cdpl-pc-08:~$ php -v PHP 5.3.3-1ubuntu9.1 with Suhosin-Patch (cli) (built: Oct 15 2010 14:17:04) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies gangzh...@cdpl-pc-08:~$ uname -a Linux CDPL-PC-08 2.6.35-24-generic #42-Ubuntu SMP Thu Dec 2 01:41:57 UTC 2010 i686 GNU/Linux Previous Comments: [2011-01-06 01:38:57] lukemoynihan at gmail dot com As a workaround until I can patch php I have used the following pure php solution: http://stackoverflow.com/questions/4610651/any-problems-with-the-following-work- around-for-php-bug-53632 [2011-01-05 19:43:21] paj...@php.net @ cswarth at gmail dot com Thanks for all the feedbacks, we had enough info and details to fix the issue and new releases will be done shortly. [2011-01-05 19:39:09] xpipe at hotmail dot de Considering the official Windows binaries are affected by this, will there be new binaries or a new PHP version released to reflect this issue? I'm asking because it is possible to take down vulnerable PHP apps by this as easily as finding a request variable that is actually accessed. Requesting viewtopic.php?f=2.2250738585072011e-308 for phpBB or index.php?q=2.2250738585072011e-308 for Drupal is enough to freeze the PHP installation if it is affected. [2011-01-05 16:27:52] jannhorn at googlemail dot com @Tyrael: Seems like it was already fixed for 5.2. http://svn.php.net/viewvc/php/php-src/branches/PHP_5_2/Zend/zend_strtod.c? view=log&pathrev=307095 [2011-01-05 16:11:19] tyra3l at gmail dot com btw. 5.2 support officially ended. are there any chances that this bug will be fixed in 5.2, or this will be the first obstacle which will force the people out there to upgrade to 5.3? Tyrael 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=53632 -- Edit this bug report at http://bugs.php.net/bug.php?id=53632&edit=1
Req #53652 [Com]: Can not define function as an array element of a class property
Edit report at http://bugs.php.net/bug.php?id=53652&edit=1
ID: 53652
Comment by: jerry at jmweb dot net
Reported by:jerry at jmweb dot net
Summary:Can not define function as an array element of a
class property
Status: Open
Type: Feature/Change Request
Package:Class/Object related
Operating System: WIN
PHP Version:5.3SVN-2011-01-04 (snap)
Block user comment: N
Private report: N
New Comment:
Felipe, thank you for the prompt response!
I assume that the reason why it is "expected" behavior and not a "bug"
is because PHP's back-end code does not accept a function declaration as
described. However, I would like to know the rationale as to why it is
not allowed when we can, for example, do the following:
class Test{
public $funcArray = array();
}
$test = new Test();
$test->funcArray = array(
'funcName' => function($a){
return $a*$a;
}
);
echo $test->funcArray['funcName'](2); // outputs 4 as expected
Given that the above example works fine, I tend to consider the absence
of the reported feature to be a "bug".
Please do not take my comments harshly. I am simply trying to understand
PHP's behavior in this situation. In fact, I greatly appreciate
everything that the PHP developers have done for the community. The PHP
language has helped me make a career and I hope to one day be able to
contribute.
Previous Comments:
[2011-01-04 22:31:09] fel...@php.net
This is currently an expected behavior.
Changed to Feature request.
[2011-01-04 19:14:37] jerry at jmweb dot net
Description:
The following error is displayed when a function is defined as an array
element of a class property.
Parse error: syntax error, unexpected T_FUNCTION in ...
This error was experienced in PHP 5.3.3 running on Apache 2.2.17 on
Windows.
Test script:
---
$funcArray = array(
'funcName' => function($a){return $a*$a;}
);
echo $funcArray['funcName'](2); // outputs 4 as expected
class testClass{
public function __construct(){}
public $funcArray = array(
'funcName' => function($a){return $a*$a;}
);
}
// The parse error is thrown for the above class definition at runtime
Expected result:
I expect the script to run without throwing an error and allow the
definition of a function as an array element of a class property just as
is the case for global arrays defined globally.
--
Edit this bug report at http://bugs.php.net/bug.php?id=53652&edit=1
Req #53659 [Opn->Asn]: Implementing RegexIterator::getRegex() method
Edit report at http://bugs.php.net/bug.php?id=53659&edit=1
ID: 53659
Updated by: ahar...@php.net
Reported by:jthijssen at noxlogic dot nl
Summary:Implementing RegexIterator::getRegex() method
-Status: Open
+Status: Assigned
Type: Feature/Change Request
Package:SPL related
Operating System: All
PHP Version:5.3SVN-2011-01-05 (SVN)
-Assigned To:
+Assigned To:aharvey
Block user comment: N
Private report: N
New Comment:
Looks good at a first pass. Let's see about getting it into trunk.
Previous Comments:
[2011-01-05 23:01:09] jthijssen at noxlogic dot nl
Description:
I'd like to see an getRegex() method in the regexIterator class that
will return the regular expression that is initialized during its
__construct().
Currently there is no way of retrieving that information except for
saving it yourself outside the object or extending regexiterator in
order to save the regex inside a custom constructor.
It would be nice if the information about the object could actually be
retrieved natively since this data is already present, just not visible
to the outside world.
Attached is a patch with an implementation.
Test script:
---
$array = array('cat', 'hat', 'sat');
$iterator = new ArrayIterator($array);
$regexIterator = new RegexIterator($iterator, '/.at/');
var_dump($regexIterator->getRegex());
Expected result:
string(5) "/.at/"
Actual result:
--
PHP Fatal error: Call to undefined method ArrayIterator::getRegex()
--
Edit this bug report at http://bugs.php.net/bug.php?id=53659&edit=1
Req #53656 [Opn->Bgs]: extend Spl-class and override a methode
Edit report at http://bugs.php.net/bug.php?id=53656&edit=1
ID: 53656
Updated by: ahar...@php.net
Reported by:coola at arcor dot de
Summary:extend Spl-class and override a methode
-Status: Open
+Status: Bogus
Type: Feature/Change Request
Package:*General Issues
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
Bugs in PECL packages, such as SPL_Types, should be reported on the
PECL bug tracker instead of this one. In this case, you can request
the feature at http://pecl.php.net/bugs/report.php?package=SPL_Types
Previous Comments:
[2011-01-05 18:59:16] coola at arcor dot de
Description:
Hi,
i would like to do something like that:
x = $x;
$this->y = $y;
}
public function splIntMethode($other, $operator) // override
SplInt-Methode
{
if($operator != '+')
throw new Exception();
if(!($other instanceof A))
throw new Exception();
return new A($x + $other->x, $y + $other->y);
}
}
$a0 = new A(1,2);
$a1 = new A(3,4); // $a1 is the '$other'-Objekt at methode
splIntMethode
$a2 = $a0 + $a1; // $operator +
?>
--
Edit this bug report at http://bugs.php.net/bug.php?id=53656&edit=1
[PHP-BUG] Bug #53662 [NEW]: strtotime() returns inconsistent output on 64 bit systems
From:
Operating system: Ubuntu 10.10
PHP version: 5.3.4
Package: Date/time related
Bug Type: Bug
Bug description:strtotime() returns inconsistent output on 64 bit systems
Description:
---
>From manual page: http://www.php.net/function.strtotime
---
strtotime() produces different output on 32 and 64 bit systems running PHP
5.3.
This affects the "zero date" ("-00-00 00:00:00") as well as dates
outside the
traditional 32 date range.
strtotime("-00-00 00:00:00") returns FALSE on a 32 bit system.
strtotime("-00-00 00:00:00") returns -62169955200 on a 64 bit system.
Test script:
---
Expected result:
On 64 bit systems, I would expect strtotime("-00-00 00:00:00") to
return
FALSE as it does on 32 bit systems.
Actual result:
--
On 64 bit systems, strtotime("-00-00 00:00:00") returns -62169955200.
--
Edit bug report at http://bugs.php.net/bug.php?id=53662&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53662&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53662&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=53662&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53662&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=53662&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53662&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=53662&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=53662&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=53662&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=53662&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=53662&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=53662&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=53662&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=53662&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53662&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=53662&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=53662&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=53662&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=53662&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=53662&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=53662&r=mysqlcfg
Bug #53662 [Opn->Bgs]: strtotime() returns inconsistent output on 64 bit systems
Edit report at http://bugs.php.net/bug.php?id=53662&edit=1
ID: 53662
Updated by: ras...@php.net
Reported by:smenjas at gmail dot com
Summary:strtotime() returns inconsistent output on 64 bit
systems
-Status: Open
+Status: Bogus
Type: Bug
Package:Date/time related
Operating System: Ubuntu 10.10
PHP Version:5.3.4
Block user comment: N
Private report: N
New Comment:
This is expected. On 64-bit systems the date range supported is much
larger than
on 32-bit systems.
Previous Comments:
[2011-01-06 02:54:19] smenjas at gmail dot com
Description:
---
>From manual page: http://www.php.net/function.strtotime
---
strtotime() produces different output on 32 and 64 bit systems running
PHP 5.3.
This affects the "zero date" ("-00-00 00:00:00") as well as dates
outside the
traditional 32 date range.
strtotime("-00-00 00:00:00") returns FALSE on a 32 bit system.
strtotime("-00-00 00:00:00") returns -62169955200 on a 64 bit
system.
Test script:
---
Expected result:
On 64 bit systems, I would expect strtotime("-00-00 00:00:00") to
return
FALSE as it does on 32 bit systems.
Actual result:
--
On 64 bit systems, strtotime("-00-00 00:00:00") returns
-62169955200.
--
Edit this bug report at http://bugs.php.net/bug.php?id=53662&edit=1
Req #53657 [Opn->Wfx]: Make at least PDOStatement::bindValue and PDOStatement::bindParam() chainable!
Edit report at http://bugs.php.net/bug.php?id=53657&edit=1
ID: 53657
Updated by: ahar...@php.net
Reported by:schindhelm at gmail dot com
Summary:Make at least PDOStatement::bindValue and
PDOStatement::bindParam() chainable!
-Status: Open
+Status: Wont fix
Type: Feature/Change Request
Package:*Database Functions
Operating System: any
PHP Version:5.3.4
Block user comment: N
Private report: N
New Comment:
The bind methods already have defined return values. I don't see any
benefit to breaking backward compatibility for such a minor potential
gain.
Previous Comments:
[2011-01-05 19:33:25] schindhelm at gmail dot com
Description:
---
>From manual page: http://www.php.net/pdostatement.bindvalue
---
The PDOStatement::bindValue and PDOStatement::bindParam methods should
be chainable. Look at my test script below for an example.
Test script:
---
// create a new PDO
$dbh = new PDO($dsn, $user, $pass);
// the example SQL statement
$sql = "INSERT INTO db.table (id, firstName, lastName) VALUES(NULL,
:firstName, :lastName)";
$statement = $dbh->prepare($sql);
// current behaviour
$statement->bindValue(':firstName', 'Foo');
$statement->bindValue(':lastName', 'Bar');
// and so on...
$statement->execute();
// what I wish for and what saves a lot of copy & paste, but especially
time
$statement->bindValue(':firstName', 'Foo')
->bindValue(':lastName', 'Bar');
->execute();
--
Edit this bug report at http://bugs.php.net/bug.php?id=53657&edit=1
Req #53652 [Opn->Dup]: Can not define function as an array element of a class property
Edit report at http://bugs.php.net/bug.php?id=53652&edit=1
ID: 53652
Updated by: ahar...@php.net
Reported by:jerry at jmweb dot net
Summary:Can not define function as an array element of a
class property
-Status: Open
+Status: Duplicate
Type: Feature/Change Request
Package:Class/Object related
Operating System: WIN
PHP Version:5.3SVN-2011-01-04 (snap)
Block user comment: N
Private report: N
New Comment:
Property initialisers have to be constant values: an anonymous
function doesn't count as a constant, just as any other non-constant
expression doesn't either.
This is a duplicate of bug #51813, which was closed by Johannes, so
I'm going to dupe this for now.
Previous Comments:
[2011-01-06 02:34:22] jerry at jmweb dot net
Felipe, thank you for the prompt response!
I assume that the reason why it is "expected" behavior and not a "bug"
is because PHP's back-end code does not accept a function declaration as
described. However, I would like to know the rationale as to why it is
not allowed when we can, for example, do the following:
class Test{
public $funcArray = array();
}
$test = new Test();
$test->funcArray = array(
'funcName' => function($a){
return $a*$a;
}
);
echo $test->funcArray['funcName'](2); // outputs 4 as expected
Given that the above example works fine, I tend to consider the absence
of the reported feature to be a "bug".
Please do not take my comments harshly. I am simply trying to understand
PHP's behavior in this situation. In fact, I greatly appreciate
everything that the PHP developers have done for the community. The PHP
language has helped me make a career and I hope to one day be able to
contribute.
[2011-01-04 22:31:09] fel...@php.net
This is currently an expected behavior.
Changed to Feature request.
[2011-01-04 19:14:37] jerry at jmweb dot net
Description:
The following error is displayed when a function is defined as an array
element of a class property.
Parse error: syntax error, unexpected T_FUNCTION in ...
This error was experienced in PHP 5.3.3 running on Apache 2.2.17 on
Windows.
Test script:
---
$funcArray = array(
'funcName' => function($a){return $a*$a;}
);
echo $funcArray['funcName'](2); // outputs 4 as expected
class testClass{
public function __construct(){}
public $funcArray = array(
'funcName' => function($a){return $a*$a;}
);
}
// The parse error is thrown for the above class definition at runtime
Expected result:
I expect the script to run without throwing an error and allow the
definition of a function as an array element of a class property just as
is the case for global arrays defined globally.
--
Edit this bug report at http://bugs.php.net/bug.php?id=53652&edit=1
Bug #53662 [Com]: strtotime() returns inconsistent output on 64 bit systems
Edit report at http://bugs.php.net/bug.php?id=53662&edit=1
ID: 53662
Comment by: smenjas at gmail dot com
Reported by:smenjas at gmail dot com
Summary:strtotime() returns inconsistent output on 64 bit
systems
Status: Bogus
Type: Bug
Package:Date/time related
Operating System: Ubuntu 10.10
PHP Version:5.3.4
Block user comment: N
Private report: N
New Comment:
Thanks for the incredibly prompt reply.
That makes sense, except that to the best of my knowledge the year zero
is not valid in either the Julian or Gregorian calendars.
I had assumed that strtotime would return FALSE for invalid dates. On
my 32 bit Ubuntu system, this appears to the case.
strtotime("2011-01-32") returns FALSE, as opposed to returning the
timestamp for "2011-02-01".
An in depth reading of the documentation did not clarify how strtotime()
should be expected to handle invalid date strings.
Previous Comments:
[2011-01-06 02:57:07] ras...@php.net
This is expected. On 64-bit systems the date range supported is much
larger than
on 32-bit systems.
[2011-01-06 02:54:19] smenjas at gmail dot com
Description:
---
>From manual page: http://www.php.net/function.strtotime
---
strtotime() produces different output on 32 and 64 bit systems running
PHP 5.3.
This affects the "zero date" ("-00-00 00:00:00") as well as dates
outside the
traditional 32 date range.
strtotime("-00-00 00:00:00") returns FALSE on a 32 bit system.
strtotime("-00-00 00:00:00") returns -62169955200 on a 64 bit
system.
Test script:
---
Expected result:
On 64 bit systems, I would expect strtotime("-00-00 00:00:00") to
return
FALSE as it does on 32 bit systems.
Actual result:
--
On 64 bit systems, strtotime("-00-00 00:00:00") returns
-62169955200.
--
Edit this bug report at http://bugs.php.net/bug.php?id=53662&edit=1
Bug #47522 [Ver->Wfx]: __toString() segfault (PHP_5_2 only)
Edit report at http://bugs.php.net/bug.php?id=47522&edit=1 ID: 47522 Updated by: ahar...@php.net Reported by:ms419 at freezone dot co dot uk Summary:__toString() segfault (PHP_5_2 only) -Status: Verified +Status: Wont fix Type: Bug Package:Reproducible crash Operating System: Debian PHP Version:5.2CVS-2009-02-27 (snap) Block user comment: N Private report: N New Comment: 5.2 is now end of lifed. Closing, since this doesn't occur on 5.3. Previous Comments: [2009-07-31 20:45:26] s...@php.net Verified for 5.2.x, not reproduceable for 5.3.x Analysis: the problem is cause by applying strpos() to Zend_Date object. When convert_to_string in strpos() is called to convert object to string, Zend_Date::__toString is called and on the course of the execution the variable stack is reallocated. However haystack variable still points to the old stack location, which means any access to it will produce the UMR. Valgrind dump: =22070== Invalid read of size 4 ==22070==at 0x81E36FB: zif_strpos (string.c:1814) ==22070==by 0x8292509: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:200) ==22070==by 0x827F6AF: execute (zend_vm_execute.h:92) ==22070==by 0x8291E75: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:234) ==22070==by 0x827F6AF: execute (zend_vm_execute.h:92) ==22070==by 0x8291E75: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:234) ==22070==by 0x827F6AF: execute (zend_vm_execute.h:92) ==22070==by 0x8291E75: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:234) ==22070==by 0x827F6AF: execute (zend_vm_execute.h:92) ==22070==by 0x8251FC7: zend_eval_string (zend_execute_API.c:1214) ==22070==by 0x825211E: zend_eval_string_ex (zend_execute_API.c:1248) ==22070==by 0x82CAACF: main (in /root/php) ==22070== Address 0x4C876E4 is 52 bytes inside a block of size 256 free'd ==22070==at 0x40054FB: realloc (vg_replace_malloc.c:306) ==22070==by 0x8291F2C: zend_do_fcall_common_helper_SPEC (zend_ptr_stack.h:73) ==22070==by 0x827F6AF: execute (zend_vm_execute.h:92) ==22070==by 0x8291E75: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:234) ==22070==by 0x827F6AF: execute (zend_vm_execute.h:92) ==22070==by 0x8291E75: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:234) ==22070==by 0x827F6AF: execute (zend_vm_execute.h:92) ==22070==by 0x8291E75: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:234) ==22070==by 0x827F6AF: execute (zend_vm_execute.h:92) ==22070==by 0x8291E75: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:234) ==22070==by 0x827F6AF: execute (zend_vm_execute.h:92) ==22070==by 0x8291E75: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:234) Not sure how to fix it. [2009-07-30 22:12:47] alex at innovacomputing dot com I'm able to reproduce this as well on PHP 5.2.9 on Debian Linux 5.0 i386, but not on amd64 versions. I was able to reproduce this by unpacking Zend Framework 1.8.4 and running the following PHP script: http://framework.zend.com/issues/browse/ZF-7413 . Here's a backtrace from gdb: #0 0x0824d2a0 in zif_strpos (ht=2, return_value=0xb6900238, return_value_ptr=0x0, this_ptr=0x0, return_value_used=1) at /usr/src/php5/source/php5-5.2.9/ext/standard/string.c:1814 #1 0x0832a413 in zend_do_fcall_common_helper_SPEC (execute_data=0xbf822cec) at /usr/src/php5/source/php5-5.2.9/Zend/zend_vm_execute.h:200 #2 0x08315580 in execute (op_array=0xb688ea80) at /usr/src/php5/source/php5-5.2.9/Zend/zend_vm_execute.h:92 #3 0x08329cd6 in zend_do_fcall_common_helper_SPEC (execute_data=0xbf82311c) at /usr/src/php5/source/php5-5.2.9/Zend/zend_vm_execute.h:234 #4 0x08315580 in execute (op_array=0xb688a90c) at /usr/src/php5/source/php5-5.2.9/Zend/zend_vm_execute.h:92 #5 0x08329cd6 in zend_do_fcall_common_helper_SPEC (execute_data=0xbf823a5c) at /usr/src/php5/source/php5-5.2.9/Zend/zend_vm_execute.h:234 #6 0x08315580 in execute (op_array=0x9c163d4) at /usr/src/php5/source/php5-5.2.9/Zend/zend_vm_execute.h:92 #7 0x08329cd6 in zend_do_fcall_common_helper_SPEC (execute_data=0xbf823c7c) at /usr/src/php5/source/php5-5.2.9/Zend/zend_vm_execute.h:234 #8 0x08315580 in execute (op_array=0x9c0dbbc) at /usr/src/php5/source/php5-5.2.9/Zend/zend_vm_execute.h:92 #9 0x082e28ce in zend_eval_string ( str=0xbf82593e "require_once \"Zend/Date.php\"; $x = new Zend_Date(); $y = new Zend_Date($x);", retval_ptr=0x0, string_name=0x8551cfc "Command line code") at /usr/src/php5/source/php5-5.2.9/Zend/zend_execute_API.c:1217 #10 0x082e2a3b in zend_eval_string_ex ( str=0xbf82593e "require_once \"Zend/Date.php\"; $x = new Zend_Date(); $y = new Zend_Date(
Req #53659 [Asn->Csd]: Implementing RegexIterator::getRegex() method
Edit report at http://bugs.php.net/bug.php?id=53659&edit=1
ID: 53659
Updated by: ahar...@php.net
Reported by:jthijssen at noxlogic dot nl
Summary:Implementing RegexIterator::getRegex() method
-Status: Assigned
+Status: Closed
Type: Feature/Change Request
Package:SPL related
Operating System: All
PHP Version:5.3SVN-2011-01-05 (SVN)
Assigned To:aharvey
Block user comment: N
Private report: N
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.
Committed on trunk: the change to the _spl_dual_it_object struct will
prevent this going into 5.3. Thanks for the patch, Joshua!
Previous Comments:
[2011-01-06 03:32:04] ahar...@php.net
Automatic comment from SVN on behalf of aharvey
Revision: http://svn.php.net/viewvc/?view=revision&revision=307147
Log: Implement request #53659 (Implementing RegexIterator::getRegex()
method). Patch
by Joshua Thijssen.
[2011-01-06 02:47:11] ahar...@php.net
Looks good at a first pass. Let's see about getting it into trunk.
[2011-01-05 23:01:09] jthijssen at noxlogic dot nl
Description:
I'd like to see an getRegex() method in the regexIterator class that
will return the regular expression that is initialized during its
__construct().
Currently there is no way of retrieving that information except for
saving it yourself outside the object or extending regexiterator in
order to save the regex inside a custom constructor.
It would be nice if the information about the object could actually be
retrieved natively since this data is already present, just not visible
to the outside world.
Attached is a patch with an implementation.
Test script:
---
$array = array('cat', 'hat', 'sat');
$iterator = new ArrayIterator($array);
$regexIterator = new RegexIterator($iterator, '/.at/');
var_dump($regexIterator->getRegex());
Expected result:
string(5) "/.at/"
Actual result:
--
PHP Fatal error: Call to undefined method ArrayIterator::getRegex()
--
Edit this bug report at http://bugs.php.net/bug.php?id=53659&edit=1
Bug #53662 [Bgs]: strtotime() returns inconsistent output on 64 bit systems
Edit report at http://bugs.php.net/bug.php?id=53662&edit=1
ID: 53662
Updated by: ahar...@php.net
Reported by:smenjas at gmail dot com
Summary:strtotime() returns inconsistent output on 64 bit
systems
Status: Bogus
Type: Bug
Package:Date/time related
Operating System: Ubuntu 10.10
PHP Version:5.3.4
Block user comment: N
Private report: N
New Comment:
PHP uses the version of the proleptic Gregorian calendar specified by
ISO 8601, which does include a year 0 (equivalent to 1 BC in the
traditional Gregorian calendar).
Previous Comments:
[2011-01-06 03:12:54] smenjas at gmail dot com
Thanks for the incredibly prompt reply.
That makes sense, except that to the best of my knowledge the year zero
is not valid in either the Julian or Gregorian calendars.
I had assumed that strtotime would return FALSE for invalid dates. On
my 32 bit Ubuntu system, this appears to the case.
strtotime("2011-01-32") returns FALSE, as opposed to returning the
timestamp for "2011-02-01".
An in depth reading of the documentation did not clarify how strtotime()
should be expected to handle invalid date strings.
[2011-01-06 02:57:07] ras...@php.net
This is expected. On 64-bit systems the date range supported is much
larger than
on 32-bit systems.
[2011-01-06 02:54:19] smenjas at gmail dot com
Description:
---
>From manual page: http://www.php.net/function.strtotime
---
strtotime() produces different output on 32 and 64 bit systems running
PHP 5.3.
This affects the "zero date" ("-00-00 00:00:00") as well as dates
outside the
traditional 32 date range.
strtotime("-00-00 00:00:00") returns FALSE on a 32 bit system.
strtotime("-00-00 00:00:00") returns -62169955200 on a 64 bit
system.
Test script:
---
Expected result:
On 64 bit systems, I would expect strtotime("-00-00 00:00:00") to
return
FALSE as it does on 32 bit systems.
Actual result:
--
On 64 bit systems, strtotime("-00-00 00:00:00") returns
-62169955200.
--
Edit this bug report at http://bugs.php.net/bug.php?id=53662&edit=1
Bug #53662 [Bgs]: strtotime() returns inconsistent output on 64 bit systems
Edit report at http://bugs.php.net/bug.php?id=53662&edit=1
ID: 53662
Updated by: ras...@php.net
Reported by:smenjas at gmail dot com
Summary:strtotime() returns inconsistent output on 64 bit
systems
Status: Bogus
Type: Bug
Package:Date/time related
Operating System: Ubuntu 10.10
PHP Version:5.3.4
Block user comment: N
Private report: N
New Comment:
And you get false in 32-bit systems because year 0 falls outside the
supported
range that fits in a 32-bit signed integer. The range for 32-bit covers
about 136
years starting at 1901-12-13 and ending at 2038-01-19
Previous Comments:
[2011-01-06 03:49:19] ahar...@php.net
PHP uses the version of the proleptic Gregorian calendar specified by
ISO 8601, which does include a year 0 (equivalent to 1 BC in the
traditional Gregorian calendar).
[2011-01-06 03:12:54] smenjas at gmail dot com
Thanks for the incredibly prompt reply.
That makes sense, except that to the best of my knowledge the year zero
is not valid in either the Julian or Gregorian calendars.
I had assumed that strtotime would return FALSE for invalid dates. On
my 32 bit Ubuntu system, this appears to the case.
strtotime("2011-01-32") returns FALSE, as opposed to returning the
timestamp for "2011-02-01".
An in depth reading of the documentation did not clarify how strtotime()
should be expected to handle invalid date strings.
[2011-01-06 02:57:07] ras...@php.net
This is expected. On 64-bit systems the date range supported is much
larger than
on 32-bit systems.
[2011-01-06 02:54:19] smenjas at gmail dot com
Description:
---
>From manual page: http://www.php.net/function.strtotime
---
strtotime() produces different output on 32 and 64 bit systems running
PHP 5.3.
This affects the "zero date" ("-00-00 00:00:00") as well as dates
outside the
traditional 32 date range.
strtotime("-00-00 00:00:00") returns FALSE on a 32 bit system.
strtotime("-00-00 00:00:00") returns -62169955200 on a 64 bit
system.
Test script:
---
Expected result:
On 64 bit systems, I would expect strtotime("-00-00 00:00:00") to
return
FALSE as it does on 32 bit systems.
Actual result:
--
On 64 bit systems, strtotime("-00-00 00:00:00") returns
-62169955200.
--
Edit this bug report at http://bugs.php.net/bug.php?id=53662&edit=1
Bug #53662 [Bgs]: strtotime() returns inconsistent output on 64 bit systems
Edit report at http://bugs.php.net/bug.php?id=53662&edit=1
ID: 53662
User updated by:smenjas at gmail dot com
Reported by:smenjas at gmail dot com
Summary:strtotime() returns inconsistent output on 64 bit
systems
Status: Bogus
Type: Bug
Package:Date/time related
Operating System: Ubuntu 10.10
PHP Version:5.3.4
Block user comment: N
Private report: N
New Comment:
Thanks for taking the time to point that out, and thanks for PHP!
Previous Comments:
[2011-01-06 04:07:00] ras...@php.net
And you get false in 32-bit systems because year 0 falls outside the
supported
range that fits in a 32-bit signed integer. The range for 32-bit covers
about 136
years starting at 1901-12-13 and ending at 2038-01-19
[2011-01-06 03:49:19] ahar...@php.net
PHP uses the version of the proleptic Gregorian calendar specified by
ISO 8601, which does include a year 0 (equivalent to 1 BC in the
traditional Gregorian calendar).
[2011-01-06 03:12:54] smenjas at gmail dot com
Thanks for the incredibly prompt reply.
That makes sense, except that to the best of my knowledge the year zero
is not valid in either the Julian or Gregorian calendars.
I had assumed that strtotime would return FALSE for invalid dates. On
my 32 bit Ubuntu system, this appears to the case.
strtotime("2011-01-32") returns FALSE, as opposed to returning the
timestamp for "2011-02-01".
An in depth reading of the documentation did not clarify how strtotime()
should be expected to handle invalid date strings.
[2011-01-06 02:57:07] ras...@php.net
This is expected. On 64-bit systems the date range supported is much
larger than
on 32-bit systems.
[2011-01-06 02:54:19] smenjas at gmail dot com
Description:
---
>From manual page: http://www.php.net/function.strtotime
---
strtotime() produces different output on 32 and 64 bit systems running
PHP 5.3.
This affects the "zero date" ("-00-00 00:00:00") as well as dates
outside the
traditional 32 date range.
strtotime("-00-00 00:00:00") returns FALSE on a 32 bit system.
strtotime("-00-00 00:00:00") returns -62169955200 on a 64 bit
system.
Test script:
---
Expected result:
On 64 bit systems, I would expect strtotime("-00-00 00:00:00") to
return
FALSE as it does on 32 bit systems.
Actual result:
--
On 64 bit systems, strtotime("-00-00 00:00:00") returns
-62169955200.
--
Edit this bug report at http://bugs.php.net/bug.php?id=53662&edit=1
