#36399 [NEW]: query from many join table in postgresql very slow
From: maccran at hotmail dot com
Operating system: freebsd 5.4
PHP version: 5.1.2
PHP Bug Type: Performance problem
Bug description: query from many join table in postgresql very slow
Description:
from the source code, the using time in this query about
7-10 ms (for exec pg_query) but when i using EXPLAIN ANALYZE in query,
postgresql say it using 0.9 ms in query, so i think it very lost time in
pg_query 5-8 ms. Because my web page have 4-10 query per page this consume
time it make my server cannot service more than 20 page/sec (1/(5 query X
10 ms), if reduce this time it very speed up my php page
this problem not appear if query from one table , but when join table more
than one table in query it happen.
in jsp&jdbc does not have any this problem
Reproduce code:
---
function microtime_float()
{list($usec, $sec) = explode(" ", microtime());
return ((float)$usec + (float)$sec);}
$q = "select a.id, b.id, c.id, d.id, e.id
from a,b,c,d,e
where a.id=b.aid and b.id=c.bid
and c.id=d.cid and d.id=e.did";
$time_start = microtime_float();
pg_query ($q);
$time_end = microtime_float();
$time = $time_end - $time_start;
--
Edit bug report at http://bugs.php.net/?id=36399&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=36399&r=trysnapshot44
Try a CVS snapshot (PHP 5.1):
http://bugs.php.net/fix.php?id=36399&r=trysnapshot51
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=36399&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=36399&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=36399&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=36399&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=36399&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=36399&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=36399&r=support
Expected behavior:http://bugs.php.net/fix.php?id=36399&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=36399&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=36399&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=36399&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36399&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=36399&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=36399&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=36399&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=36399&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=36399&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=36399&r=mysqlcfg
#36389 [Fbk->Opn]: error on binding result parameter for prepared statement
ID: 36389
User updated by: camka at email dot ee
Reported By: camka at email dot ee
-Status: Feedback
+Status: Open
Bug Type: MySQLi related
Operating System: win xp
PHP Version: 5.1.2
Assigned To: georg
New Comment:
The latest PHP extension + mysql client API lib from mysql.com solved
the problem.
Thanks a lot.
Previous Comments:
[2006-02-15 08:37:53] [EMAIL PROTECTED]
Please try latest version from
http://dev.mysql.com/downloads/connector/php/
[2006-02-14 23:22:21] [EMAIL PROTECTED]
Georg, please take a look at it.
Looks like another client<->server version incompatibility and/or
windows weirdness.
Not reproducible on Linux with MySQL 5.0.16.
[2006-02-14 23:15:25] camka at email dot ee
problem remains
[2006-02-14 18:24:33] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.1-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.1-win32-latest.zip
[2006-02-14 12:52:04] camka at email dot ee
Description:
When trying to bind a result variable to a prepared statement the error
"Using unsupported buffer type: 253" comes up.
Moreover, the binded in paramter doesn't get binded correctly either as
seen from mysql log.
The other strange thing is that, if field datatype varchar(15) (< then
16) is used for tm table, than error 253 won't come up, buth the
problem with binded parameter remains. Integer type works without the
error as well.
Tested with both current stable php version and the latest snapshot
(Built On: Feb 14, 2006 11:30 GMT)
Reproduce code:
---
query("select @@version as v")->fetch_assoc();
echo "\nMySQL version: ".$v['v'];
$m->query("create temporary table tm (txt varchar(16))");
$m->query("insert into tm (txt) values ('2'),('3'),('4')");
$v = $m->query("select count(*) as v from tm")->fetch_assoc();
echo "\nNum of recs: ".$v['v'];
$str = "select txt from tm where txt=?";
$ps = $m->prepare($str);
$txt_in = '2';
$txt_out = null;
if (!$ps->bind_param('s', $txt_in)) echo "\nbind_param: ".$ps->error;
if (!$ps->bind_result($txt_out))echo "\nbind_result: ".$ps->error;
if ($ps->execute()) echo "\nexecuted successfully:
".$ps->num_rows;
elseecho "\nfailed ps execution:
".$ps->error;
if (!$ps->store_result()) echo "\nstore_result:
".$ps->error;
if ($z = $ps->fetch()) echo "\nfetched successfully:
".$txt_out;
elseif($z === false)echo "\nfailed fetching:
".$ps->error;
elseif($z === null) echo "\nno more records";
?>
Expected result:
PHP version: 5.1.2
MySQL version: 5.0.18-nt-log
Num of recs: 3
executed successfully: 0
fetched successfully: 1
Actual result:
--
PHP version: 5.1.2
MySQL version: 5.0.18-nt-log
Num of recs: 3
bind_result: Using unsupported buffer type: 253 (parameter: 1)
executed successfully: 0
no more records
[mysql log file]
58 Query select @@version as v
58 Query create temporary table tm (txt varchar(16))
58 Query insert into tm (txt) values ('2'),('3'),('4')
58 Query select count(*) as v from tm
58 Prepare [1]
58 Execute [1] select txt from tm where txt=0
--
Edit this bug report at http://bugs.php.net/?id=36389&edit=1
#36399 [Opn->Bgs]: query from many join table in postgresql very slow
ID: 36399
Updated by: [EMAIL PROTECTED]
Reported By: maccran at hotmail dot com
-Status: Open
+Status: Bogus
Bug Type: Performance problem
Operating System: freebsd 5.4
PHP Version: 5.1.2
New Comment:
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
Not PHP problem.
Previous Comments:
[2006-02-15 09:15:44] maccran at hotmail dot com
Description:
from the source code, the using time in this query about
7-10 ms (for exec pg_query) but when i using EXPLAIN ANALYZE in query,
postgresql say it using 0.9 ms in query, so i think it very lost time
in pg_query 5-8 ms. Because my web page have 4-10 query per page this
consume time it make my server cannot service more than 20 page/sec
(1/(5 query X 10 ms), if reduce this time it very speed up my php page
this problem not appear if query from one table , but when join table
more than one table in query it happen.
in jsp&jdbc does not have any this problem
Reproduce code:
---
function microtime_float()
{list($usec, $sec) = explode(" ", microtime());
return ((float)$usec + (float)$sec);}
$q = "select a.id, b.id, c.id, d.id, e.id
from a,b,c,d,e
where a.id=b.aid and b.id=c.bid
and c.id=d.cid and d.id=e.did";
$time_start = microtime_float();
pg_query ($q);
$time_end = microtime_float();
$time = $time_end - $time_start;
--
Edit this bug report at http://bugs.php.net/?id=36399&edit=1
#36389 [Opn->Bgs]: error on binding result parameter for prepared statement
ID: 36389 Updated by: [EMAIL PROTECTED] Reported By: camka at email dot ee -Status: Open +Status: Bogus Bug Type: MySQLi related Operating System: win xp PHP Version: 5.1.2 Assigned To: georg New Comment: Not PHP problem. Previous Comments: [2006-02-15 09:39:25] camka at email dot ee The latest PHP extension + mysql client API lib from mysql.com solved the problem. Thanks a lot. [2006-02-15 08:37:53] [EMAIL PROTECTED] Please try latest version from http://dev.mysql.com/downloads/connector/php/ [2006-02-14 23:22:21] [EMAIL PROTECTED] Georg, please take a look at it. Looks like another client<->server version incompatibility and/or windows weirdness. Not reproducible on Linux with MySQL 5.0.16. [2006-02-14 23:15:25] camka at email dot ee problem remains [2006-02-14 18:24:33] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip 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/36389 -- Edit this bug report at http://bugs.php.net/?id=36389&edit=1
#36400 [NEW]: Custom 5xx error does not return correct HTTP response error code
From: paolo at casarini dot org Operating system: Linux version 2.4.27-2-386 PHP version: 5.1.2 PHP Bug Type: Apache related Bug description: Custom 5xx error does not return correct HTTP response error code Description: When running PHP as an Apache module (Apache/1.3.34 (Debian) PHP/5.1.2-1.dotdeb.2 mod_ssl/2.8.25 OpenSSL/0.9.8), the response error code for a custom error is not correctly returned. Reproduce code: --- \n"; echo "\n"; echo "Error on page!!!\n"; echo "\n"; echo "\n"; ?> Expected result: I would expect to see an HTTP response code of 559 with a response message of "CustomError". Actual result: -- The response code returned is 500. -- Edit bug report at http://bugs.php.net/?id=36400&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=36400&r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=36400&r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=36400&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=36400&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=36400&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=36400&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=36400&r=needscript Try newer version:http://bugs.php.net/fix.php?id=36400&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=36400&r=support Expected behavior:http://bugs.php.net/fix.php?id=36400&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=36400&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=36400&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=36400&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36400&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=36400&r=dst IIS Stability:http://bugs.php.net/fix.php?id=36400&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=36400&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=36400&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=36400&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=36400&r=mysqlcfg
#36400 [Opn->Csd]: Custom 5xx error does not return correct HTTP response error code
ID: 36400 Updated by: [EMAIL PROTECTED] Reported By: paolo at casarini dot org -Status: Open +Status: Closed Bug Type: Apache related Operating System: Linux version 2.4.27-2-386 PHP Version: 5.1.2 New Comment: This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2006-02-15 10:12:11] paolo at casarini dot org Description: When running PHP as an Apache module (Apache/1.3.34 (Debian) PHP/5.1.2-1.dotdeb.2 mod_ssl/2.8.25 OpenSSL/0.9.8), the response error code for a custom error is not correctly returned. Reproduce code: --- \n"; echo "\n"; echo "Error on page!!!\n"; echo "\n"; echo "\n"; ?> Expected result: I would expect to see an HTTP response code of 559 with a response message of "CustomError". Actual result: -- The response code returned is 500. -- Edit this bug report at http://bugs.php.net/?id=36400&edit=1
#36401 [NEW]: Bug in mktime()
From: marcel dot alburg at alkronet dot info
Operating system: Linux
PHP version: 5.1.2
PHP Bug Type: Date/time related
Bug description: Bug in mktime()
Description:
If i enter
print mktime(0,0,0,0,0,0)
i get "943916400" but it must be "0"
print date('r', mktime(0,0,0,0,0,0));
returns
Tue, 30 Nov 1999 00:00:00 +0100
Marcel Alburg
Reproduce code:
---
print mktime(0,0,0,0,0,0);
returns 943916400
Expected result:
mktime(0,0,0,0,0,0) must be 0
--
Edit bug report at http://bugs.php.net/?id=36401&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=36401&r=trysnapshot44
Try a CVS snapshot (PHP 5.1):
http://bugs.php.net/fix.php?id=36401&r=trysnapshot51
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=36401&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=36401&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=36401&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=36401&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=36401&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=36401&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=36401&r=support
Expected behavior:http://bugs.php.net/fix.php?id=36401&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=36401&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=36401&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=36401&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36401&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=36401&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=36401&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=36401&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=36401&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=36401&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=36401&r=mysqlcfg
#36401 [Opn->Bgs]: Bug in mktime()
ID: 36401
Updated by: [EMAIL PROTECTED]
Reported By: marcel dot alburg at alkronet dot info
-Status: Open
+Status: Bogus
Bug Type: Date/time related
Operating System: Linux
PHP Version: 5.1.2
New Comment:
Why? The result is correct. You're getting the timestamp for 0
january-1 (december of the previous year), year 0 (which is 2000) at
00:00:00. This is exactly 30 november 1999, 00:00:00
Previous Comments:
[2006-02-15 13:31:15] marcel dot alburg at alkronet dot info
Description:
If i enter
print mktime(0,0,0,0,0,0)
i get "943916400" but it must be "0"
print date('r', mktime(0,0,0,0,0,0));
returns
Tue, 30 Nov 1999 00:00:00 +0100
Marcel Alburg
Reproduce code:
---
print mktime(0,0,0,0,0,0);
returns 943916400
Expected result:
mktime(0,0,0,0,0,0) must be 0
--
Edit this bug report at http://bugs.php.net/?id=36401&edit=1
#36401 [Bgs]: Bug in mktime()
ID: 36401
User updated by: marcel dot alburg at alkronet dot info
Reported By: marcel dot alburg at alkronet dot info
Status: Bogus
Bug Type: Date/time related
Operating System: Linux
PHP Version: 5.1.2
New Comment:
but in previosly versions it get 0 back.
because that i mean it's an error
thanks
marcel alburg
Previous Comments:
[2006-02-15 13:35:19] [EMAIL PROTECTED]
Why? The result is correct. You're getting the timestamp for 0
january-1 (december of the previous year), year 0 (which is 2000) at
00:00:00. This is exactly 30 november 1999, 00:00:00
[2006-02-15 13:31:15] marcel dot alburg at alkronet dot info
Description:
If i enter
print mktime(0,0,0,0,0,0)
i get "943916400" but it must be "0"
print date('r', mktime(0,0,0,0,0,0));
returns
Tue, 30 Nov 1999 00:00:00 +0100
Marcel Alburg
Reproduce code:
---
print mktime(0,0,0,0,0,0);
returns 943916400
Expected result:
mktime(0,0,0,0,0,0) must be 0
--
Edit this bug report at http://bugs.php.net/?id=36401&edit=1
#25876 [Com]: session_start(): Failed to initialize storage module
ID: 25876 Comment by: jjohanso at online dot no Reported By: golden at riscom dot com Status: No Feedback Bug Type: Session related Operating System: freebsd 4.8 PHP Version: 4.3.9-4.3.10 Assigned To: sniper New Comment: Running with this configuration, FreeBSD FreeBSD 5.2.1-RELEASE-p9 #0: Wed Aug 4 19:02:38 CEST 2004 Database Version: MySQL 4.0.18 PHP Version: 4.3.11 Web Server: Apache/2.0.52 (FreeBSD) PHP/4.3.11 WebServer to PHP interface: apache2handler session.save_handler in php.ini set to files, I see this problem with a low frequency (maybe 2-3 times every second day when working with updates to my CMS system all day). Doing a web search in the CMS community it seems that a number of people is strugling with this problem... Previous Comments: [2005-12-20 18:06:25] siggi at junesystems dot com A workaround for this problem is to reset the session handlers for PHP before calling session_start for the second time. You can use the session_set_save_handler() function for this. [2005-12-08 07:59:46] henmarrina at gmail dot com while i was working on joomla admin module i got this error: Fatal error: session_start(): Failed to initialize storage module. in /var/www/html/workspace/joomla/administrator/index2.php on line 34 as suggested by may forum i have changed session.save_handler in php.ini to files. but error is still thereis there any concrete solution for this problem [2005-12-02 13:11:04] ts at dreamcoder dot dk Without knowing about the code side of it, this bug reminds me of the php_value leak there was amoung virtualhosts in apache once - where the php_value_* from one virtualhost was leaked in to another. [2005-10-30 16:11:13] support3 at futurahost dot com Hello We "solved" it by adding an auto_prepend file to every .php executed on our servers: [EMAIL PROTECTED] lib]$ cat php.ini.prepend [EMAIL PROTECTED] lib]$ grep auto_prepend_file php.ini auto_prepend_file = /usr/local/lib/php.ini.prepend [EMAIL PROTECTED] lib]$ Anyway, we are very concerned about php developers completely ignoring this bug. [2005-09-30 20:32:42] dan at nitro dot com I was experiencing this problem on my server, and have managed to make it go away after reading comments in this post and experimenting a bit. details: original setup: /var/lib/php/session owner root:apache permissions: 770 test script from gul_murjani at yahoo dot com would fail after between 1 and 30 or so counts modified permissions on directory to: owner apache:apache permissions 700 test script ran on five client computers to over 10,000 cycles without failing. this fix is strange though as I have since changed the permissions back to the origial setup: owner root:apache permissions: 770 and the script has run without failing - no more errors - even after another thousands of cycles. strange but true! 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/25876 -- Edit this bug report at http://bugs.php.net/?id=25876&edit=1
#36402 [NEW]: PDO_MYSQL prepared statements cause Out of memory or data corruption
From: joh at deworks dot net
Operating system: Linux
PHP version: 5CVS-2006-02-15 (snap)
PHP Bug Type: PDO related
Bug description: PDO_MYSQL prepared statements cause Out of memory or data
corruption
Description:
PDO_MYSQL prepared statement INSERTs either result in corrupt data or
SQLSTATE[HY000]: General error: 5 Out of memory (Needed 4261477896 bytes)
This works perfectly with PDO_SQLITE.
Reproduce code:
---
CREATE TABLE test (id INT PRIMARY KEY AUTO_INCREMENT, col1 VARCHAR(255),
col2 VARCHAR(255), col3 VARCHAR(255), col4 VARCHAR(255), col5
VARCHAR(255));
$dbh = new PDO('mysql:host=localhost;dbname=...', '...', '...');
$sql = 'INSERT INTO test(col1, col2, col3, col4, col5) VALUES(:col1,
:col2, :col3, :col4, :col5)';
$stmt = DB::$dbh->prepare($sql);
$col1 = 'TestCol1';
$col2 = 'TestCol2';
$col3 = 'TestCol3';
$col4 = 'TestCol4';
$col5 = 'TestCol5';
$stmt->bindParam(':col1', $col1);
$stmt->bindParam(':col2', $col2);
$stmt->bindParam(':col3', $col3);
$stmt->bindParam(':col4', $col4);
$stmt->bindParam(':col5', $col5);
$stmt->execute();
Expected result:
No outupt, mysql table test contains rows according to the query.
Actual result:
--
Fatal error: Uncaught exception 'PDOException' with message
'SQLSTATE[HY000]: General error: 2013 Lost connection to MySQL server
during query' in file.php:125
Stack trace:
#0 file.php(125): PDOStatement->execute()
#1 {main}
thrown in file.php on line 125
Decreasing the number of parameters to 4 (col1, col2, col3, col4) results
in:
Fatal error: Uncaught exception 'PDOException' with message
'SQLSTATE[HY000]: General error: 5 Out of memory (Needed 4261477896
bytes)' in file.php:141
Stack trace:
#0 file.php(141): PDOStatement->execute()
#1 {main}
thrown in file.php on line 141
Decreasing the number of parameters to 3 or less (here: col1, col2, col3)
results in a successfull query, but corrupt inserted data:
mysql> SELECT * FROM test;
++--+--+--+--+--+
| id | col1 | col2 | col3 | col4 | col5 |
++--+--+--+--+--+
| 2 | | \u| | NULL | NULL |
++--+--+--+--+--+
1 row in set (0.00 sec)
--
Edit bug report at http://bugs.php.net/?id=36402&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=36402&r=trysnapshot44
Try a CVS snapshot (PHP 5.1):
http://bugs.php.net/fix.php?id=36402&r=trysnapshot51
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=36402&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=36402&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=36402&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=36402&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=36402&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=36402&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=36402&r=support
Expected behavior:http://bugs.php.net/fix.php?id=36402&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=36402&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=36402&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=36402&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36402&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=36402&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=36402&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=36402&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=36402&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=36402&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=36402&r=mysqlcfg
#36402 [Opn]: PDO_MYSQL prepared statements cause Out of memory or data corruption
ID: 36402
User updated by: joh at deworks dot net
Reported By: joh at deworks dot net
Status: Open
Bug Type: PDO related
Operating System: Linux
PHP Version: 5CVS-2006-02-15 (snap)
New Comment:
Forgot to mention that I'm running MySQL 4.1.12
Previous Comments:
[2006-02-15 15:02:29] joh at deworks dot net
Description:
PDO_MYSQL prepared statement INSERTs either result in corrupt data or
SQLSTATE[HY000]: General error: 5 Out of memory (Needed 4261477896
bytes)
This works perfectly with PDO_SQLITE.
Reproduce code:
---
CREATE TABLE test (id INT PRIMARY KEY AUTO_INCREMENT, col1
VARCHAR(255), col2 VARCHAR(255), col3 VARCHAR(255), col4 VARCHAR(255),
col5 VARCHAR(255));
$dbh = new PDO('mysql:host=localhost;dbname=...', '...', '...');
$sql = 'INSERT INTO test(col1, col2, col3, col4, col5) VALUES(:col1,
:col2, :col3, :col4, :col5)';
$stmt = DB::$dbh->prepare($sql);
$col1 = 'TestCol1';
$col2 = 'TestCol2';
$col3 = 'TestCol3';
$col4 = 'TestCol4';
$col5 = 'TestCol5';
$stmt->bindParam(':col1', $col1);
$stmt->bindParam(':col2', $col2);
$stmt->bindParam(':col3', $col3);
$stmt->bindParam(':col4', $col4);
$stmt->bindParam(':col5', $col5);
$stmt->execute();
Expected result:
No outupt, mysql table test contains rows according to the query.
Actual result:
--
Fatal error: Uncaught exception 'PDOException' with message
'SQLSTATE[HY000]: General error: 2013 Lost connection to MySQL server
during query' in file.php:125
Stack trace:
#0 file.php(125): PDOStatement->execute()
#1 {main}
thrown in file.php on line 125
Decreasing the number of parameters to 4 (col1, col2, col3, col4)
results in:
Fatal error: Uncaught exception 'PDOException' with message
'SQLSTATE[HY000]: General error: 5 Out of memory (Needed 4261477896
bytes)' in file.php:141
Stack trace:
#0 file.php(141): PDOStatement->execute()
#1 {main}
thrown in file.php on line 141
Decreasing the number of parameters to 3 or less (here: col1, col2,
col3) results in a successfull query, but corrupt inserted data:
mysql> SELECT * FROM test;
++--+--+--+--+--+
| id | col1 | col2 | col3 | col4 | col5 |
++--+--+--+--+--+
| 2 | | \u| | NULL | NULL |
++--+--+--+--+--+
1 row in set (0.00 sec)
--
Edit this bug report at http://bugs.php.net/?id=36402&edit=1
#36401 [Bgs->Opn]: Bug in mktime()
ID: 36401
Updated by: [EMAIL PROTECTED]
Reported By: marcel dot alburg at alkronet dot info
-Status: Bogus
+Status: Open
Bug Type: Date/time related
Operating System: Linux
PHP Version: 5.1.2
New Comment:
Ah, but, the documentation says:
"If the arguments are invalid (eg. if the year, month and day are all
0), the function returns FALSE (before PHP 5.1 it returned -1)."
Furthermore, I've just tested on an ancient PHP 4.0 I had lying around,
and mktime(0,0,0,0,0,0) does indeed return -1.
So it seems there's something to be resolved here, whether it be fixing
mktime or changing the documentation.
Previous Comments:
[2006-02-15 13:42:42] marcel dot alburg at alkronet dot info
but in previosly versions it get 0 back.
because that i mean it's an error
thanks
marcel alburg
[2006-02-15 13:35:19] [EMAIL PROTECTED]
Why? The result is correct. You're getting the timestamp for 0
january-1 (december of the previous year), year 0 (which is 2000) at
00:00:00. This is exactly 30 november 1999, 00:00:00
[2006-02-15 13:31:15] marcel dot alburg at alkronet dot info
Description:
If i enter
print mktime(0,0,0,0,0,0)
i get "943916400" but it must be "0"
print date('r', mktime(0,0,0,0,0,0));
returns
Tue, 30 Nov 1999 00:00:00 +0100
Marcel Alburg
Reproduce code:
---
print mktime(0,0,0,0,0,0);
returns 943916400
Expected result:
mktime(0,0,0,0,0,0) must be 0
--
Edit this bug report at http://bugs.php.net/?id=36401&edit=1
#36402 [Opn->Fbk]: PDO_MYSQL prepared statements cause Out of memory or data corruption
ID: 36402
Updated by: [EMAIL PROTECTED]
Reported By: joh at deworks dot net
-Status: Open
+Status: Feedback
Bug Type: PDO related
Operating System: Linux
PHP Version: 5CVS-2006-02-15 (snap)
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5.1-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.1-win32-latest.zip
Previous Comments:
[2006-02-15 15:04:05] joh at deworks dot net
Forgot to mention that I'm running MySQL 4.1.12
[2006-02-15 15:02:29] joh at deworks dot net
Description:
PDO_MYSQL prepared statement INSERTs either result in corrupt data or
SQLSTATE[HY000]: General error: 5 Out of memory (Needed 4261477896
bytes)
This works perfectly with PDO_SQLITE.
Reproduce code:
---
CREATE TABLE test (id INT PRIMARY KEY AUTO_INCREMENT, col1
VARCHAR(255), col2 VARCHAR(255), col3 VARCHAR(255), col4 VARCHAR(255),
col5 VARCHAR(255));
$dbh = new PDO('mysql:host=localhost;dbname=...', '...', '...');
$sql = 'INSERT INTO test(col1, col2, col3, col4, col5) VALUES(:col1,
:col2, :col3, :col4, :col5)';
$stmt = DB::$dbh->prepare($sql);
$col1 = 'TestCol1';
$col2 = 'TestCol2';
$col3 = 'TestCol3';
$col4 = 'TestCol4';
$col5 = 'TestCol5';
$stmt->bindParam(':col1', $col1);
$stmt->bindParam(':col2', $col2);
$stmt->bindParam(':col3', $col3);
$stmt->bindParam(':col4', $col4);
$stmt->bindParam(':col5', $col5);
$stmt->execute();
Expected result:
No outupt, mysql table test contains rows according to the query.
Actual result:
--
Fatal error: Uncaught exception 'PDOException' with message
'SQLSTATE[HY000]: General error: 2013 Lost connection to MySQL server
during query' in file.php:125
Stack trace:
#0 file.php(125): PDOStatement->execute()
#1 {main}
thrown in file.php on line 125
Decreasing the number of parameters to 4 (col1, col2, col3, col4)
results in:
Fatal error: Uncaught exception 'PDOException' with message
'SQLSTATE[HY000]: General error: 5 Out of memory (Needed 4261477896
bytes)' in file.php:141
Stack trace:
#0 file.php(141): PDOStatement->execute()
#1 {main}
thrown in file.php on line 141
Decreasing the number of parameters to 3 or less (here: col1, col2,
col3) results in a successfull query, but corrupt inserted data:
mysql> SELECT * FROM test;
++--+--+--+--+--+
| id | col1 | col2 | col3 | col4 | col5 |
++--+--+--+--+--+
| 2 | | \u| | NULL | NULL |
++--+--+--+--+--+
1 row in set (0.00 sec)
--
Edit this bug report at http://bugs.php.net/?id=36402&edit=1
#16263 [Com]: session.start() create new empty session file and not resume existing session
ID: 16263 Comment by: bohn at netbuild dot net Reported By: kur at natur dot cuni dot cz Status: No Feedback Bug Type: Session related Operating System: ANY PHP Version: 4.3.0-dev New Comment: got same problem under using php 4.3.10 :( on heavy load, php creates a new session... fc3, apache2, php4.3.10, lvs Previous Comments: [2006-01-30 22:21:11] geso at inmail dot sk I've got same problem with 5.1.2 (and previously with 4.3.8). Both clean install, Win2k, IIS 5.0. Everytime I enter (reload) a page, it creates a new file in my sessions directory. [2005-11-15 16:25:07] f dot schiappelli at enpam dot it Same problem with PHP 5.0.2, Apache 2.0.52, Windows XP. Did anybody solved the problem? Thanks in advance, Faith [2005-10-26 17:21:19] beny dot eleeas at gmail dot com I got the same problem in PHP 4.3.10. What should I do? System Linux Build Date Dec 18 2004 22:24:47 Server API CGI Virtual Directory Support disabled Configuration File (php.ini) Path /home/lib/php/php.ini PHP API 20020918 PHP Extension 20020429 Zend Extension 20021010 Debug Build no Thread Safety disabled Registered PHP Streams php, http, ftp, https, ftps session.cache_limiter nocache session.cookie_domain no value session.cookie_lifetime 0 session.cookie_path / session.cookie_secure Off session.entropy_file /dev/urandom session.entropy_length 64 session.gc_divisor 100 session.gc_maxlifetime 1440 session.gc_probability 1 session.name PHPSESSID session.referer_check no value session.save_handler files session.save_path /home/var/state/php session.serialize_handler php session.use_cookies On session.use_only_cookies Off session.use_trans_sid Off [2005-09-19 17:34:10] bananen_007 at hotmail dot com Just wanted to say that I got the same problem in PHP 5.0.5 clean installation with Apache 2.x.x. Reading\Writing to session works in the same page but the server loses the session when going between different pages or reloading the page. [2005-07-13 04:36:59] beredim at hotmail dot com Same here using PHP 5.0.4 Apache 2.0.54 Windows XP SP2 (up to date) 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/16263 -- Edit this bug report at http://bugs.php.net/?id=16263&edit=1
#36383 [Fbk->Opn]: ob_implicit_flush() does not disable output buffering
ID: 36383 User updated by: david at acz dot org Reported By: david at acz dot org -Status: Feedback +Status: Open Bug Type: Output Control Operating System: Linux -PHP Version: 5.1.2 +PHP Version: 5.1-200602151530 New Comment: Same thing: php5.1-200602151530$ sapi/cgi/php -q bool(true) Another test: php5.1-200602151530$ sapi/cgi/php -q (no output) The ob_implicit_flush() function is not disabling output buffering or sending the current output as the documentation says it should. Previous Comments: [2006-02-13 19:09:07] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip [2006-02-13 17:09:57] david at acz dot org Description: The documentation for ob_implicit_flush says that "Turning implicit flushing on will disable output buffering, the output buffers current output will be sent as if ob_end_flush() had been called." This is not the case. If this is indeed the correct behavior, please update the documentation to reflect that and add an example such as the following: ob_implicit_flush(true); while (@ob_end_flush()); Reproduce code: --- ob_start(); ob_implicit_flush(true); var_dump(ob_end_flush()); Expected result: bool(false) Actual result: -- bool(true) -- Edit this bug report at http://bugs.php.net/?id=36383&edit=1
#36403 [NEW]: oci_execute() no longer supports OCI_DESCRIBE_ONLY
From: johnw at sussex dot ac dot uk
Operating system: solaris 9
PHP version: 5.1.2
PHP Bug Type: OCI8 related
Bug description: oci_execute() no longer supports OCI_DESCRIBE_ONLY
Description:
Supplying the constant OCI_DESCRIBE_ONLY as the second
argument (mode) to oci_execute() results in a warning,
and oci_execute() returning false.
Reproduce code:
---
The bug is caused by these lines of code in
php-5.1.2/ext/oci8/oci_statement.c
at line 1351 in the definition of
php_oci_statement_execute():
switch (mode) {
case OCI_COMMIT_ON_SUCCESS:
case OCI_DEFAULT:
/* only these two are allowed */
break;
default:
php_error_docref(NULL TSRMLS_CC, E_WARNING,
"Invalid execute mode given: %d", mode);
return 1;
break;
}
Expected result:
I would expect oci_execute() to pass the mode
OCI_DESCRIBE_ONLY on to the underlying OCI8 call.
I think it is very bad that this non- backward-
compatible change has been made without being documented
or announced anywhere. I am responsible for an
application that is used by several thousands of users
daily that relies on OCI_DESCRIBE_ONLY working.
--
Edit bug report at http://bugs.php.net/?id=36403&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=36403&r=trysnapshot44
Try a CVS snapshot (PHP 5.1):
http://bugs.php.net/fix.php?id=36403&r=trysnapshot51
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=36403&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=36403&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=36403&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=36403&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=36403&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=36403&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=36403&r=support
Expected behavior:http://bugs.php.net/fix.php?id=36403&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=36403&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=36403&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=36403&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36403&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=36403&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=36403&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=36403&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=36403&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=36403&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=36403&r=mysqlcfg
#25475 [Com]: Direct IO access to raw file descriptor
ID: 25475 Comment by: php at kanarpiet dot com Reported By: mbostrom at syrah dot us Status: Open Bug Type: Feature/Change Request Operating System: Unixes PHP Version: Irrelevant New Comment: It would indeed be very nice to be able to use the extra file descriptors opened by the parents proc_open() call. However, you should also be able to use the normal fgets() and fputs() functions, not just the Direct IO ones. Previous Comments: [2003-09-10 15:08:40] mbostrom at syrah dot us Description: The Direct IO functions are nice. However, it is sometimes necessary to access file descriptors by their number. For instance, a parent process can set up file descriptors 3, 4 and 5 for communication with the a child process (in addition to file descriptors 0, 1 and 2). It would be nice if there were a way in PHP to get access to to file descriptor 3, so that PHP could interoperate with software that uses "extra" file descriptors. (In particular, I am writing a mail filter. The mail server sets up fd 3). Getting access to the "extra" file descriptors is not possible at present, because the only way to get a file descriptor is to call dio_open on a file. What if the file descriptor already exists? There is currently no way to access it. Perhaps a function such as dio_rawfd (int fdnum) could be added? fdnum is an integer - the number of the file descriptor you want. dio_rawfd returns a file descriptor resource for file descriptor number fdnum. -- Edit this bug report at http://bugs.php.net/?id=25475&edit=1
#36387 [Bgs]: rewind() does not work on Bzip2 handles
ID: 36387 User updated by: creg dot douglaus at gmail dot com Reported By: creg dot douglaus at gmail dot com Status: Bogus Bug Type: Bzip2 Related Operating System: Windows XP, SP2 PHP Version: 5.1.2 New Comment: Perhaps it should support seeking to make it parallel with the other functions? Previous Comments: [2006-02-15 08:37:32] [EMAIL PROTECTED] Warning: rewind(): stream does not support seeking The error message is quite descriptive. [2006-02-14 22:13:27] creg dot douglaus at gmail dot com [2006-02-14 08:57:47] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If possible, make the script source available online and provide an URL to it here. Try to avoid embedding huge scripts into the report. [2006-02-14 01:17:47] creg dot douglaus at gmail dot com Description: rewind() and fseeking to position zero do not work on Bzip2 file handles. As it works with gz-file pointers, it should work with Bzip2 file pointers as well... This is an issue across all versions of PHP... -- Edit this bug report at http://bugs.php.net/?id=36387&edit=1
#36387 [Bgs]: rewind() does not work on Bzip2 handles
ID: 36387 Updated by: [EMAIL PROTECTED] Reported By: creg dot douglaus at gmail dot com Status: Bogus Bug Type: Bzip2 Related Operating System: Windows XP, SP2 PHP Version: 5.1.2 New Comment: I'm afraid there is no such possibility at all or do you have a patch? Previous Comments: [2006-02-15 21:02:19] creg dot douglaus at gmail dot com Perhaps it should support seeking to make it parallel with the other functions? [2006-02-15 08:37:32] [EMAIL PROTECTED] Warning: rewind(): stream does not support seeking The error message is quite descriptive. [2006-02-14 22:13:27] creg dot douglaus at gmail dot com [2006-02-14 08:57:47] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If possible, make the script source available online and provide an URL to it here. Try to avoid embedding huge scripts into the report. [2006-02-14 01:17:47] creg dot douglaus at gmail dot com Description: rewind() and fseeking to position zero do not work on Bzip2 file handles. As it works with gz-file pointers, it should work with Bzip2 file pointers as well... This is an issue across all versions of PHP... -- Edit this bug report at http://bugs.php.net/?id=36387&edit=1
#36403 [Opn->Csd]: oci_execute() no longer supports OCI_DESCRIBE_ONLY
ID: 36403
Updated by: [EMAIL PROTECTED]
Reported By: johnw at sussex dot ac dot uk
-Status: Open
+Status: Closed
Bug Type: OCI8 related
Operating System: solaris 9
PHP Version: 5.1.2
New Comment:
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2006-02-15 19:01:26] johnw at sussex dot ac dot uk
Description:
Supplying the constant OCI_DESCRIBE_ONLY as the second
argument (mode) to oci_execute() results in a warning,
and oci_execute() returning false.
Reproduce code:
---
The bug is caused by these lines of code in
php-5.1.2/ext/oci8/oci_statement.c
at line 1351 in the definition of
php_oci_statement_execute():
switch (mode) {
case OCI_COMMIT_ON_SUCCESS:
case OCI_DEFAULT:
/* only these two are allowed */
break;
default:
php_error_docref(NULL TSRMLS_CC, E_WARNING,
"Invalid execute mode given: %d", mode);
return 1;
break;
}
Expected result:
I would expect oci_execute() to pass the mode
OCI_DESCRIBE_ONLY on to the underlying OCI8 call.
I think it is very bad that this non- backward-
compatible change has been made without being documented
or announced anywhere. I am responsible for an
application that is used by several thousands of users
daily that relies on OCI_DESCRIBE_ONLY working.
--
Edit this bug report at http://bugs.php.net/?id=36403&edit=1
#36402 [Fbk->Opn]: PDO_MYSQL prepared statements cause Out of memory or data corruption
ID: 36402
User updated by: joh at deworks dot net
Reported By: joh at deworks dot net
-Status: Feedback
+Status: Open
Bug Type: PDO related
Operating System: Linux
PHP Version: 5CVS-2006-02-15 (snap)
New Comment:
I've tried the latest snapshot (I tried it before I reported this bug),
and the problem still persists. Sorry.
Previous Comments:
[2006-02-15 16:45:41] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.1-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.1-win32-latest.zip
[2006-02-15 15:04:05] joh at deworks dot net
Forgot to mention that I'm running MySQL 4.1.12
[2006-02-15 15:02:29] joh at deworks dot net
Description:
PDO_MYSQL prepared statement INSERTs either result in corrupt data or
SQLSTATE[HY000]: General error: 5 Out of memory (Needed 4261477896
bytes)
This works perfectly with PDO_SQLITE.
Reproduce code:
---
CREATE TABLE test (id INT PRIMARY KEY AUTO_INCREMENT, col1
VARCHAR(255), col2 VARCHAR(255), col3 VARCHAR(255), col4 VARCHAR(255),
col5 VARCHAR(255));
$dbh = new PDO('mysql:host=localhost;dbname=...', '...', '...');
$sql = 'INSERT INTO test(col1, col2, col3, col4, col5) VALUES(:col1,
:col2, :col3, :col4, :col5)';
$stmt = DB::$dbh->prepare($sql);
$col1 = 'TestCol1';
$col2 = 'TestCol2';
$col3 = 'TestCol3';
$col4 = 'TestCol4';
$col5 = 'TestCol5';
$stmt->bindParam(':col1', $col1);
$stmt->bindParam(':col2', $col2);
$stmt->bindParam(':col3', $col3);
$stmt->bindParam(':col4', $col4);
$stmt->bindParam(':col5', $col5);
$stmt->execute();
Expected result:
No outupt, mysql table test contains rows according to the query.
Actual result:
--
Fatal error: Uncaught exception 'PDOException' with message
'SQLSTATE[HY000]: General error: 2013 Lost connection to MySQL server
during query' in file.php:125
Stack trace:
#0 file.php(125): PDOStatement->execute()
#1 {main}
thrown in file.php on line 125
Decreasing the number of parameters to 4 (col1, col2, col3, col4)
results in:
Fatal error: Uncaught exception 'PDOException' with message
'SQLSTATE[HY000]: General error: 5 Out of memory (Needed 4261477896
bytes)' in file.php:141
Stack trace:
#0 file.php(141): PDOStatement->execute()
#1 {main}
thrown in file.php on line 141
Decreasing the number of parameters to 3 or less (here: col1, col2,
col3) results in a successfull query, but corrupt inserted data:
mysql> SELECT * FROM test;
++--+--+--+--+--+
| id | col1 | col2 | col3 | col4 | col5 |
++--+--+--+--+--+
| 2 | | \u| | NULL | NULL |
++--+--+--+--+--+
1 row in set (0.00 sec)
--
Edit this bug report at http://bugs.php.net/?id=36402&edit=1
#36404 [NEW]: configure script cannot complete libxml build
From: davecenker at cfl dot rr dot com
Operating system: Solaris 8
PHP version: 5.1.2
PHP Bug Type: *Compile Issues
Bug description: configure script cannot complete libxml build
Description:
I am having difficulties getting past the libxml build check when
configuring PHP. I have installed libxml version 2.6.23 and am attempting
to run the configure script for PHP version 5.1.2. I have seen other bug
reports similar to this, but none of the recommended fixes seem to address
my problem.
Below is the complete configure commandline:
./configure --with-apxs=/home/dcenker/AMP/apache/bin/apxs
--with-mysqli=/home/dcenker/AMP/mysql/bin/mysql_config --enable-mbstring
--enable-soap --with-libxml-dir=/home/dcenker/libxml
where /home/dcenker/libxml/bin contains the xml2-config executable. The
last few lines of the config.log file are as follows:
Any help in resolving this installation issue would be greatly
appreciated. If you need any additional information, please let me know.
Thank you.
Actual result:
--
<<>>
configure:18440: checking whether to enable LIBXML support
configure:18487: checking libxml2 install dir
configure:18647: checking whether libxml build works
configure:18674: gcc -o conftest -g -O2 -D_POSIX_PTHREAD_SEMANTICS
-R/usr/ucbli
b -L/usr/ucblib -R/apps/gcc-3.0.4/lib/gcc-lib/sparc-sun-solaris2.7/3.0.4
-L/apps/
gcc-3.0.4/lib/gcc-lib/sparc-sun-solaris2.7/3.0.4
-R/home/dcenker/libxml/lib -L/ho
me/dcenker/libxml/lib conftest.c
-lresolv -lm -ldl -lnsl -lsocket -lgcc -lxml2 -lz -lm -lsocket
-lnsl 1>
&5
configure: failed program was:
#line 18663 "configure"
#include "confdefs.h"
char xmlInitParser();
int main() {
xmlInitParser();
return 0;
}
<<>>
--
Edit bug report at http://bugs.php.net/?id=36404&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=36404&r=trysnapshot44
Try a CVS snapshot (PHP 5.1):
http://bugs.php.net/fix.php?id=36404&r=trysnapshot51
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=36404&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=36404&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=36404&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=36404&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=36404&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=36404&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=36404&r=support
Expected behavior:http://bugs.php.net/fix.php?id=36404&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=36404&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=36404&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=36404&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36404&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=36404&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=36404&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=36404&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=36404&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=36404&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=36404&r=mysqlcfg
#35671 [Com]: Named parameters not working in PDO_ODBC
ID: 35671
Comment by: stoens at activegrid dot com
Reported By: mknobloch at midstate dot edu
Status: Assigned
Bug Type: PDO related
Operating System: Windows 2003 SP1
PHP Version: 5.1.2
Assigned To: wez
New Comment:
I am seeing the same thing with the OCI and the ODBC drivers on Windows
and Linux (FC4). Same PHP version.
Previous Comments:
[2006-01-12 17:32:07] mknobloch at midstate dot edu
This bug still exists in 5.1.2.
It can be worked around by replacing php_pdo.dll and php_pdo_odbc.dll
with their counterparts from 5.1.0, but it would be nice to have it
fixed.
[2005-12-16 11:43:03] [EMAIL PROTECTED]
assigned to the maintainer.
[2005-12-15 14:33:41] mknobloch at midstate dot edu
The problem still exists in the 200512151130 Win32 snapshot.
[2005-12-14 21:04:50] mknobloch at midstate dot edu
Description:
When using a named parameters array, PDO_ODBC substitutes the last
value in the array for each named parameter.
This code works fine in 5.1.0. The bug first appeared in 5.1.1. I can
also confirm that this bug does not affect PDO_SQLITE.
Reproduce code:
---
$dbh = new PDO("odbc:testdb");
$dbh->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_WARNING);
$sql = "INSERT INTO testtable (field1, field2, field3) VALUES (:value1,
:value2, :value3)";
$sth = $dbh->prepare($sql, array(PDO::ATTR_CURSOR,
PDO::CURSOR_FWDONLY));
$parm = array(
":value1" => 15,
":value2" => 20,
":value3" => 25
);
$sth->execute($parm);
Expected result:
I expect a new record to be inserted into the table with field1 = 15,
field2 = 20, and field3 = 25
Actual result:
--
A new record is created, but 25 is inserted into all three fields.
--
Edit this bug report at http://bugs.php.net/?id=35671&edit=1
#36405 [NEW]: inline assignment of a variable used as a reference fails
From: thom at genx dot net Operating system: Linux (gentoo) PHP version: 5.1.2 PHP Bug Type: Scripting Engine problem Bug description: inline assignment of a variable used as a reference fails Description: Inline assignment of a variable used as an argument to a function (passed by reference) does not behave properly. Earlier versions of PHP (< 5.1.2) and other programming languages recognize the assignment before the function call is made. It seems that PHP 5.1.2 recognizes the assignment after the function call is made. Reproduce code: --- Expected result: footestAppend Actual result: -- foo -- Edit bug report at http://bugs.php.net/?id=36405&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=36405&r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=36405&r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=36405&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=36405&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=36405&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=36405&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=36405&r=needscript Try newer version:http://bugs.php.net/fix.php?id=36405&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=36405&r=support Expected behavior:http://bugs.php.net/fix.php?id=36405&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=36405&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=36405&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=36405&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36405&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=36405&r=dst IIS Stability:http://bugs.php.net/fix.php?id=36405&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=36405&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=36405&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=36405&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=36405&r=mysqlcfg
#36405 [Opn->Bgs]: inline assignment of a variable used as a reference fails
ID: 36405 Updated by: [EMAIL PROTECTED] Reported By: thom at genx dot net -Status: Open +Status: Bogus Bug Type: Scripting Engine problem Operating System: Linux (gentoo) PHP Version: 5.1.2 New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php $x = 'foo' is an expression and cannot be passed by reference. Enable E_STRICT to see the message. Previous Comments: [2006-02-16 00:33:18] thom at genx dot net Description: Inline assignment of a variable used as an argument to a function (passed by reference) does not behave properly. Earlier versions of PHP (< 5.1.2) and other programming languages recognize the assignment before the function call is made. It seems that PHP 5.1.2 recognizes the assignment after the function call is made. Reproduce code: --- Expected result: footestAppend Actual result: -- foo -- Edit this bug report at http://bugs.php.net/?id=36405&edit=1
#36405 [Bgs->Opn]: inline assignment of a variable used as a reference fails
ID: 36405
User updated by: thom at genx dot net
Reported By: thom at genx dot net
-Status: Bogus
+Status: Open
Bug Type: Scripting Engine problem
Operating System: Linux (gentoo)
PHP Version: 5.1.2
New Comment:
Maybe this is not a good argument, but other languages still interpret
that as passing $x by reference, but to do the assigment first. I am
going to use C++ as an example (since PHP has tried to model some of
its behavior from):
#include
using namespace std;
void
foo(int &x)
{
x = 9;
}
int
main()
{
int x;
foo(x = 1);
cout << x << "\n";
}
The output is: 9
There are no compiler warnings or errors (at the highest reporting
level). I understand that this is not C++, but previous versions of
PHP (< 5.1.2) behaved consistently with other programming languages in
the way that inline assignments were handled.
Is it something the PHP development team would consider (reverting back
to a more consistent behavior)?
Thanks,
thom
Previous Comments:
[2006-02-16 01:15:45] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
$x = 'foo' is an expression and cannot be passed by reference. Enable
E_STRICT to see the message.
[2006-02-16 00:33:18] thom at genx dot net
Description:
Inline assignment of a variable used as an argument to a function
(passed by reference) does not behave properly. Earlier versions of
PHP (< 5.1.2) and other programming languages recognize the assignment
before the function call is made. It seems that PHP 5.1.2 recognizes
the assignment after the function call is made.
Reproduce code:
---
Expected result:
footestAppend
Actual result:
--
foo
--
Edit this bug report at http://bugs.php.net/?id=36405&edit=1
#36405 [Opn->Bgs]: inline assignment of a variable used as a reference fails
ID: 36405
Updated by: [EMAIL PROTECTED]
Reported By: thom at genx dot net
-Status: Open
+Status: Bogus
Bug Type: Scripting Engine problem
Operating System: Linux (gentoo)
PHP Version: 5.1.2
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Read the manual, the definition of an expression and a variable are
clearly explained. And keep it this bug as bogus it is not a bug (and
the behavior is documented).
Previous Comments:
[2006-02-16 01:43:39] thom at genx dot net
Maybe this is not a good argument, but other languages still interpret
that as passing $x by reference, but to do the assigment first. I am
going to use C++ as an example (since PHP has tried to model some of
its behavior from):
#include
using namespace std;
void
foo(int &x)
{
x = 9;
}
int
main()
{
int x;
foo(x = 1);
cout << x << "\n";
}
The output is: 9
There are no compiler warnings or errors (at the highest reporting
level). I understand that this is not C++, but previous versions of
PHP (< 5.1.2) behaved consistently with other programming languages in
the way that inline assignments were handled.
Is it something the PHP development team would consider (reverting back
to a more consistent behavior)?
Thanks,
thom
[2006-02-16 01:15:45] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
$x = 'foo' is an expression and cannot be passed by reference. Enable
E_STRICT to see the message.
[2006-02-16 00:33:18] thom at genx dot net
Description:
Inline assignment of a variable used as an argument to a function
(passed by reference) does not behave properly. Earlier versions of
PHP (< 5.1.2) and other programming languages recognize the assignment
before the function call is made. It seems that PHP 5.1.2 recognizes
the assignment after the function call is made.
Reproduce code:
---
Expected result:
footestAppend
Actual result:
--
foo
--
Edit this bug report at http://bugs.php.net/?id=36405&edit=1
#36407 [NEW]: Encoding in xsl:output has no effect
From: memoimyself at yahoo dot com dot br
Operating system: Windows XP
PHP version: 5.1.2
PHP Bug Type: XSLT related
Bug description: Encoding in xsl:output has no effect
Description:
I have an XSL file to transform XML documents; the XSL and all XML files
are encoded in UTF-8. My PHP script is in a file also encoded in UTF-8.
The data is retrieved from a database (MySQL 5) whose character set is
UTF-8 and whose tables all have UTF-8 as their character set as well. All
the strings in all the tables are duly encoded in UTF-8. Prior to data
retrieval, the query 'SET NAMES "utf8"' is run to ensure that all i/o
operations use the same character set (UTF-8). (Hope I've been thorough
enough!)
Now, my XSL file has the following top-level (child node of the document
element, as it should be) element:
The transformation is performed by the transformToXML method of the
XSLTProcessor class.
When the code is run on a Windows server (Win XP, Apache 2.0.55,PHP
5.1.2), the result of the transformation is NEVER UTF-8 (always
iso-8859-1), even if I chage 'method' to 'xml', and even if I use a
'media-type' attribute.
When run on a Linux server (PHP 5.1.2 as well), everything goes well.
Reproduce code:
---
$xml = new DOMDocument('1.0', 'UTF-8');
$xml->loadXML($row->Report);
$xsl = new DOMDocument('1.0', 'UTF-8');
$xsl->load($xsl_file);
$proc = new XSLTProcessor;
$proc->importStyleSheet($xsl);
$report = $proc->transformToXML($xml);
Expected result:
Output string should be encoded in UTF-8.
Actual result:
--
Output string in NOT encoded in UTF-8 and accented characters appear
garbled. This problem only occurs under Windows.
--
Edit bug report at http://bugs.php.net/?id=36407&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=36407&r=trysnapshot44
Try a CVS snapshot (PHP 5.1):
http://bugs.php.net/fix.php?id=36407&r=trysnapshot51
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=36407&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=36407&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=36407&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=36407&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=36407&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=36407&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=36407&r=support
Expected behavior:http://bugs.php.net/fix.php?id=36407&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=36407&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=36407&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=36407&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36407&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=36407&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=36407&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=36407&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=36407&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=36407&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=36407&r=mysqlcfg
#36405 [Bgs]: inline assignment of a variable used as a reference fails
ID: 36405
User updated by: thom at genx dot net
Reported By: thom at genx dot net
Status: Bogus
-Bug Type: Scripting Engine problem
+Bug Type: Feature/Change Request
Operating System: Linux (gentoo)
PHP Version: 5.1.2
New Comment:
Sorry, I left it as 'Bogus' this time. I thought that meant it was
closed and that any further responses were ignored.
This is changed to a Feature/Change request in hopes that it will
receive some attention and/or debate.
Thanks.
Previous Comments:
[2006-02-16 01:58:35] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Read the manual, the definition of an expression and a variable are
clearly explained. And keep it this bug as bogus it is not a bug (and
the behavior is documented).
[2006-02-16 01:43:39] thom at genx dot net
Maybe this is not a good argument, but other languages still interpret
that as passing $x by reference, but to do the assigment first. I am
going to use C++ as an example (since PHP has tried to model some of
its behavior from):
#include
using namespace std;
void
foo(int &x)
{
x = 9;
}
int
main()
{
int x;
foo(x = 1);
cout << x << "\n";
}
The output is: 9
There are no compiler warnings or errors (at the highest reporting
level). I understand that this is not C++, but previous versions of
PHP (< 5.1.2) behaved consistently with other programming languages in
the way that inline assignments were handled.
Is it something the PHP development team would consider (reverting back
to a more consistent behavior)?
Thanks,
thom
[2006-02-16 01:15:45] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
$x = 'foo' is an expression and cannot be passed by reference. Enable
E_STRICT to see the message.
[2006-02-16 00:33:18] thom at genx dot net
Description:
Inline assignment of a variable used as an argument to a function
(passed by reference) does not behave properly. Earlier versions of
PHP (< 5.1.2) and other programming languages recognize the assignment
before the function call is made. It seems that PHP 5.1.2 recognizes
the assignment after the function call is made.
Reproduce code:
---
Expected result:
footestAppend
Actual result:
--
foo
--
Edit this bug report at http://bugs.php.net/?id=36405&edit=1
#36398 [Bgs->Opn]: "make test" should be fully scriptable [Do not prompt for email address]
ID: 36398 User updated by: nickj-phpbugs at nickj dot org Reported By: nickj-phpbugs at nickj dot org -Status: Bogus +Status: Open Bug Type: Feature/Change Request Operating System: Linux PHP Version: 5.1.2 New Comment: Thank you - that sort of helps, and I realise now that I should have phrased my request better (so I have reopened, and rephrased it to hopefully be clearer). What I mostly wanted was to run the tests, and then email the results off, without prompting. I can enable/disable the prompt now with: TEST_PHP_ARGS="-q" make test And I can see the available options with: TEST_PHP_EXECUTABLE="/root/tmp/php-5.1-dev/php5.1-200602150330/sapi/cli/php" sapi/cli/php run-tests.php --help However, unless I am mistaken, I can't see any option to specify the email address to use, such as for example: TEST_PHP_ARGS="--email-results [EMAIL PROTECTED]" make test My underlying assumption here is that you folks want and use the output of "make test" in some way. If that's not the case, then of course, don't make it an option. However, if you are using this, then wouldn't it be good to be able to script it so that it could automatically email off the results of make test, without having to prompt the user? Then you could (for example) have the build farm automatically email the qa.php.net list with the results of "make test" after every build of every snapshot. Maybe you already do this in some other way, but if not, it seems like it could be useful to me. You could also update http://qa.php.net/running-tests.php with this information, so that people could "set and forget" to run the tests and email the results, without prompting them. P.s. there is a very small typo in the help for "make test". It says "-q Quite, no user interaction"; but you want it to say "Quiet", not "Quite". Previous Comments: [2006-02-15 08:48:46] [EMAIL PROTECTED] You can already do this, set the env variable TEST_PHP_ARGS to "-q" and it should skip the question. Use -h to get all available options. [2006-02-15 06:56:06] nickj-phpbugs at nickj dot org Description: I have a little shell script to download PHP snapshots, extract them, configure them, and build them. I would like to add automatically running "make test" on them. However, it does not appear that this can be done at the moment, because "make test" prompts the user for information after running tests, like so: You may have found a problem in PHP. We would like to send this report automatically to the PHP QA team, to give us a better understanding of how the test cases are doing. If you don't want to send it immediately, you can choose "s" to save the report to a file that you can send us later. Do you want to send this report now? [Yns]: Please enter your email address. (Your address will be mangled so that it will not go out on any mailinglist in plain text): It would be really useful if "make test" could be fully scripted, so that it did not ask for whether to send email, and what email address to send it from. For example, if you could do this, then that would be ideal: make test --email-report [EMAIL PROTECTED] -- Edit this bug report at http://bugs.php.net/?id=36398&edit=1
#36398 [Opn]: "make test" should be fully scriptable [Do not prompt for email address]
ID: 36398 Updated by: [EMAIL PROTECTED] Reported By: nickj-phpbugs at nickj dot org Status: Open Bug Type: Feature/Change Request Operating System: Linux PHP Version: 5.1.2 New Comment: Thanks, I've just fixed the typo. As for the request - I'm pretty sure you can add it to run-tests.php and send a patch for us to review. Though, I don't know if we really want php-qa list to get filled with results of the tests executed automatically every X minutes. Previous Comments: [2006-02-16 06:19:59] nickj-phpbugs at nickj dot org Thank you - that sort of helps, and I realise now that I should have phrased my request better (so I have reopened, and rephrased it to hopefully be clearer). What I mostly wanted was to run the tests, and then email the results off, without prompting. I can enable/disable the prompt now with: TEST_PHP_ARGS="-q" make test And I can see the available options with: TEST_PHP_EXECUTABLE="/root/tmp/php-5.1-dev/php5.1-200602150330/sapi/cli/php" sapi/cli/php run-tests.php --help However, unless I am mistaken, I can't see any option to specify the email address to use, such as for example: TEST_PHP_ARGS="--email-results [EMAIL PROTECTED]" make test My underlying assumption here is that you folks want and use the output of "make test" in some way. If that's not the case, then of course, don't make it an option. However, if you are using this, then wouldn't it be good to be able to script it so that it could automatically email off the results of make test, without having to prompt the user? Then you could (for example) have the build farm automatically email the qa.php.net list with the results of "make test" after every build of every snapshot. Maybe you already do this in some other way, but if not, it seems like it could be useful to me. You could also update http://qa.php.net/running-tests.php with this information, so that people could "set and forget" to run the tests and email the results, without prompting them. P.s. there is a very small typo in the help for "make test". It says "-q Quite, no user interaction"; but you want it to say "Quiet", not "Quite". [2006-02-15 08:48:46] [EMAIL PROTECTED] You can already do this, set the env variable TEST_PHP_ARGS to "-q" and it should skip the question. Use -h to get all available options. [2006-02-15 06:56:06] nickj-phpbugs at nickj dot org Description: I have a little shell script to download PHP snapshots, extract them, configure them, and build them. I would like to add automatically running "make test" on them. However, it does not appear that this can be done at the moment, because "make test" prompts the user for information after running tests, like so: You may have found a problem in PHP. We would like to send this report automatically to the PHP QA team, to give us a better understanding of how the test cases are doing. If you don't want to send it immediately, you can choose "s" to save the report to a file that you can send us later. Do you want to send this report now? [Yns]: Please enter your email address. (Your address will be mangled so that it will not go out on any mailinglist in plain text): It would be really useful if "make test" could be fully scripted, so that it did not ask for whether to send email, and what email address to send it from. For example, if you could do this, then that would be ideal: make test --email-report [EMAIL PROTECTED] -- Edit this bug report at http://bugs.php.net/?id=36398&edit=1
#36405 [Bgs]: inline assignment of a variable used as a reference fails
ID: 36405
Updated by: [EMAIL PROTECTED]
Reported By: thom at genx dot net
Status: Bogus
Bug Type: Feature/Change Request
Operating System: Linux (gentoo)
PHP Version: 5.1.2
New Comment:
No, it won't change.
Expressions are expressions, you can't pass them by reference.
Previous Comments:
[2006-02-16 02:17:39] thom at genx dot net
Sorry, I left it as 'Bogus' this time. I thought that meant it was
closed and that any further responses were ignored.
This is changed to a Feature/Change request in hopes that it will
receive some attention and/or debate.
Thanks.
[2006-02-16 01:58:35] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Read the manual, the definition of an expression and a variable are
clearly explained. And keep it this bug as bogus it is not a bug (and
the behavior is documented).
[2006-02-16 01:43:39] thom at genx dot net
Maybe this is not a good argument, but other languages still interpret
that as passing $x by reference, but to do the assigment first. I am
going to use C++ as an example (since PHP has tried to model some of
its behavior from):
#include
using namespace std;
void
foo(int &x)
{
x = 9;
}
int
main()
{
int x;
foo(x = 1);
cout << x << "\n";
}
The output is: 9
There are no compiler warnings or errors (at the highest reporting
level). I understand that this is not C++, but previous versions of
PHP (< 5.1.2) behaved consistently with other programming languages in
the way that inline assignments were handled.
Is it something the PHP development team would consider (reverting back
to a more consistent behavior)?
Thanks,
thom
[2006-02-16 01:15:45] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
$x = 'foo' is an expression and cannot be passed by reference. Enable
E_STRICT to see the message.
[2006-02-16 00:33:18] thom at genx dot net
Description:
Inline assignment of a variable used as an argument to a function
(passed by reference) does not behave properly. Earlier versions of
PHP (< 5.1.2) and other programming languages recognize the assignment
before the function call is made. It seems that PHP 5.1.2 recognizes
the assignment after the function call is made.
Reproduce code:
---
Expected result:
footestAppend
Actual result:
--
foo
--
Edit this bug report at http://bugs.php.net/?id=36405&edit=1
#36410 [NEW]: usleep() do strange behavior
From: sqchen at citiz dot net Operating system: redhat 7.3 PHP version: 5.1.2 PHP Bug Type: Unknown/Other Function Bug description: usleep() do strange behavior Description: there are two questions: first: usleep(21474809); usleep(21474909); second: usleep(-1); usleep(-21474809); Actual result: -- first: usleep(21474809) wait for a long time (I am not sure hong long?) usleep(21474909) wait for 1 second second: usleep(-1) wait for a long time usleep(-21474809) wait for 0 second -- Edit bug report at http://bugs.php.net/?id=36410&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=36410&r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=36410&r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=36410&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=36410&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=36410&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=36410&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=36410&r=needscript Try newer version:http://bugs.php.net/fix.php?id=36410&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=36410&r=support Expected behavior:http://bugs.php.net/fix.php?id=36410&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=36410&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=36410&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=36410&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36410&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=36410&r=dst IIS Stability:http://bugs.php.net/fix.php?id=36410&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=36410&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=36410&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=36410&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=36410&r=mysqlcfg
