#42722 [Com]: display_errors setting ignored for E_PARSE and HTTP 500 page
ID: 42722 Comment by: dan at yes dot lt Reported By: mabismad at msn dot com Status: No Feedback Bug Type: *General Issues Operating System: WinXP PHP Version: 5.2.4 Assigned To: dmitry New Comment: this bug still was not fixed Previous Comments: [2007-10-09 01:00:00] 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". [2007-10-03 10:19:09] alahaye at fm2i dot com Is the same for me with PHP 5.2.4 for a development server : Here my php.ini configuration : error_reporting = E_ALL & ~E_NOTICE display_errors = On log_errors = On error_log = /var/log/php/php_error.log With this simple code : === I get on screen : HTTP 500 internal error Error is log on my file /var/log/php/php_error.log BUT no error display on screen (expected is : PHP Parse error: syntax error, unexpected $end in error.php on line X) Can you give us more information about "Changed error handler to send HTTP 500 instead of blank page on PHP errors." How to display error on browser like in previous version. When you are 10 developper on the server and don't have access to the Apache log file it's not usefull. Thx. [2007-10-01 10:48:11] [EMAIL PROTECTED] I cannot reproduce it with CVS version. $ sapi/cgi/php-cgi -d display_errors=0 -d error_reporting=E_ALL wrong.php Status: 500 Internal Server Error X-Powered-By: PHP/5.3.0-dev Content-type: text/html $ sapi/cgi/php-cgi -d display_errors=1 -d error_reporting=E_ALL wrong.php X-Powered-By: PHP/5.3.0-dev Content-type: text/html Parse error: syntax error, unexpected T_STRING in /home/dmitry/php/php5.3/CGI-DEBUG/x.php on line 2 /home/dmitry/php/php5.3/CGI-DEBUG/wrong.php(2) : Parse error - syntax error, unexpected T_STRING [2007-09-30 21:37:28] [EMAIL PROTECTED] Dmitry, please check this out. [2007-09-21 02:22:49] mabismad at msn dot com Description: The display errors and error reporting change to accomplish the following - "Changed error handler to send HTTP 500 instead of blank page on PHP errors. (Dmitry, Andrei Nigmatulin)" - apparently does not check if there is actual output due to the display errors/error reporting settings. When display_errors is set to On and error_reporting is set to E_ALL, only Notice and Warning level messages are output to the browser. Fatal parse errors (and probably other types) unconditionally cause a HTTP 500 page. The HTTP 500 redirect should only occur when there is absolutely no actual output from any of the display errors/error reporting settings. -- Edit this bug report at http://bugs.php.net/?id=42722&edit=1
#41727 [Bgs]: ArrayAccess::offsetExists works wrong with isset()
ID: 41727
User updated by: dan at yes dot lt
Reported By: dan at yes dot lt
Status: Bogus
Bug Type: SPL related
Operating System: WinXP
PHP Version: 5.2.3
New Comment:
I see... you make php for yourself, but not for others... you don't
listen for arguments, just skipping the bugs... without any reason
explanations...
thank you for good support and correct php!
Previous Comments:
[2007-06-22 10:29:15] [EMAIL PROTECTED]
.
[2007-06-22 07:46:23] dan at yes dot lt
ok, now think... if you have method to work with array or any object
with ArrayAccess implemented...
function some($list)
{
if (isset($list[0])) {
// do something with $list[0]
return true;
} else {
// no $list[0] defined, skipping
return false;
}
}
user, who implements this function must not know the real type of the
$list variable - but only that this variable can be accessed as
array...
now - if $list = array(0 => null), then this function works correctly,
but if $list = new ArrayObject(array(0 => null)), then it fails...
now, you say, i must to use offsetGet method... then, i must check
whether $list is instance of ArrayAccess, then add complex checkings
using offsetExists and offsetGet... was the ArrayAccess realy planned to
be such a silly structure to use it in such complex way?.. I don't think
so. I still think, isset() must automaticaly call offsetGet after
offsetExists returns true...
[2007-06-22 07:34:01] [EMAIL PROTECTED]
Yes, I still think so.
[2007-06-22 04:38:24] dan at yes dot lt
isset Determine whether a variable is set
[http://php.net/isset]
array_key_exists Checks if the given key or index exists in the
array
[http://php.net/array-key-exists]
10, 1 => null);
// so...
var_dump(isset($a[0])); // bool(true)
var_dump(array_key_exists(0, $a)); // bool(true)
// but...
var_dump(isset($a[1])); // bool(false)
var_dump(array_key_exists(0, $a)); // bool(true)
?>
now...
ArrayObject::offsetExists Returns whether the requested $index
exists
[http://php.net/ArrayObject-offsetExists]
so, offsetExists must return the same as array_key_exists... but how
isset() must work with ArrayAccess?..
10, 1 => null));
// so...
var_dump(isset($a[0])); // bool(true)
var_dump($a->offsetExists(0)); // bool(true)
var_dump(array_key_exists(0, $a)); // bool(true)
// but...
var_dump(isset($a[1])); // bool(true) | false expected
var_dump($a->offsetExists(1)); // bool(true)
var_dump(array_key_exists(1, $a)); // bool(true)
?>
in this case isset() returns true, but obviously must return false...
don't you think so?.. isn't this situation silly?..
and do you still think - "this is not a bug"?..
[2007-06-21 21:55:36] [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
You can call offsetGet() yourself if you want.
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/41727
--
Edit this bug report at http://bugs.php.net/?id=41727&edit=1
#41727 [Bgs->Opn]: ArrayAccess::offsetExists works wrong with isset()
ID: 41727
User updated by: dan at yes dot lt
Reported By: dan at yes dot lt
-Status: Bogus
+Status: Open
Bug Type: SPL related
Operating System: WinXP
PHP Version: 5.2.3
New Comment:
ok, now think... if you have method to work with array or any object
with ArrayAccess implemented...
function some($list)
{
if (isset($list[0])) {
// do something with $list[0]
return true;
} else {
// no $list[0] defined, skipping
return false;
}
}
user, who implements this function must not know the real type of the
$list variable - but only that this variable can be accessed as
array...
now - if $list = array(0 => null), then this function works correctly,
but if $list = new ArrayObject(array(0 => null)), then it fails...
now, you say, i must to use offsetGet method... then, i must check
whether $list is instance of ArrayAccess, then add complex checkings
using offsetExists and offsetGet... was the ArrayAccess realy planned to
be such a silly structure to use it in such complex way?.. I don't think
so. I still think, isset() must automaticaly call offsetGet after
offsetExists returns true...
Previous Comments:
[2007-06-22 07:34:01] [EMAIL PROTECTED]
Yes, I still think so.
[2007-06-22 04:38:24] dan at yes dot lt
isset Determine whether a variable is set
[http://php.net/isset]
array_key_exists Checks if the given key or index exists in the
array
[http://php.net/array-key-exists]
10, 1 => null);
// so...
var_dump(isset($a[0])); // bool(true)
var_dump(array_key_exists(0, $a)); // bool(true)
// but...
var_dump(isset($a[1])); // bool(false)
var_dump(array_key_exists(0, $a)); // bool(true)
?>
now...
ArrayObject::offsetExists Returns whether the requested $index
exists
[http://php.net/ArrayObject-offsetExists]
so, offsetExists must return the same as array_key_exists... but how
isset() must work with ArrayAccess?..
10, 1 => null));
// so...
var_dump(isset($a[0])); // bool(true)
var_dump($a->offsetExists(0)); // bool(true)
var_dump(array_key_exists(0, $a)); // bool(true)
// but...
var_dump(isset($a[1])); // bool(true) | false expected
var_dump($a->offsetExists(1)); // bool(true)
var_dump(array_key_exists(1, $a)); // bool(true)
?>
in this case isset() returns true, but obviously must return false...
don't you think so?.. isn't this situation silly?..
and do you still think - "this is not a bug"?..
[2007-06-21 21:55:36] [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
You can call offsetGet() yourself if you want.
--------------------
[2007-06-18 13:00:54] dan at yes dot lt
Description:
method ArrayAccess actualy works wrong with isset()/empty()...
isset()/empty() now calls only ArrayAccess::offsetExist, but should
call both ArrayAccess::offsetExist and ArrayAccess::offsetGet to check
if value is realy set.
that's how arrays do...
Reproduce code:
---
class Test implements ArrayAccess
{
protected $_array = array();
protected $_count = 0;
function offsetExists($offset)
{
return $offset >= 0 && $offset < $this->_count;
}
function offsetGet($offset)
{
return $this->_array[$offset];
}
function offsetSet($offset, $value)
{
$this->_array[] = $value;
$this->_count++;
}
function offsetUnset($offset)
{
unset($this->_array[$offset]);
}
}
$a = new Test;
$a[] = 'A'; // 0
$a[] = 10; // 1
$a[] = null; // 2
echo isset($a[0]) ? 'set' : 'unset', "\n";
echo isset($a[1]) ? 'set' : 'unset', "\n";
echo isset($a[2]) ? 'set' : 'unset', "\n";
Expected result:
set
set
unset
Actual result:
--
set
set
set
--
Edit this bug report at http://bugs.php.net/?id=41727&edit=1
#41727 [Bgs->Opn]: ArrayAccess::offsetExists works wrong with isset()
ID: 41727
User updated by: dan at yes dot lt
Reported By: dan at yes dot lt
-Status: Bogus
+Status: Open
Bug Type: SPL related
Operating System: WinXP
PHP Version: 5.2.3
New Comment:
isset Determine whether a variable is set
[http://php.net/isset]
array_key_exists Checks if the given key or index exists in the
array
[http://php.net/array-key-exists]
10, 1 => null);
// so...
var_dump(isset($a[0])); // bool(true)
var_dump(array_key_exists(0, $a)); // bool(true)
// but...
var_dump(isset($a[1])); // bool(false)
var_dump(array_key_exists(0, $a)); // bool(true)
?>
now...
ArrayObject::offsetExists Returns whether the requested $index
exists
[http://php.net/ArrayObject-offsetExists]
so, offsetExists must return the same as array_key_exists... but how
isset() must work with ArrayAccess?..
10, 1 => null));
// so...
var_dump(isset($a[0])); // bool(true)
var_dump($a->offsetExists(0)); // bool(true)
var_dump(array_key_exists(0, $a)); // bool(true)
// but...
var_dump(isset($a[1])); // bool(true) | false expected
var_dump($a->offsetExists(1)); // bool(true)
var_dump(array_key_exists(1, $a)); // bool(true)
?>
in this case isset() returns true, but obviously must return false...
don't you think so?.. isn't this situation silly?..
and do you still think - "this is not a bug"?..
Previous Comments:
[2007-06-21 21:55:36] [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
You can call offsetGet() yourself if you want.
----------------
[2007-06-18 13:00:54] dan at yes dot lt
Description:
method ArrayAccess actualy works wrong with isset()/empty()...
isset()/empty() now calls only ArrayAccess::offsetExist, but should
call both ArrayAccess::offsetExist and ArrayAccess::offsetGet to check
if value is realy set.
that's how arrays do...
Reproduce code:
---
class Test implements ArrayAccess
{
protected $_array = array();
protected $_count = 0;
function offsetExists($offset)
{
return $offset >= 0 && $offset < $this->_count;
}
function offsetGet($offset)
{
return $this->_array[$offset];
}
function offsetSet($offset, $value)
{
$this->_array[] = $value;
$this->_count++;
}
function offsetUnset($offset)
{
unset($this->_array[$offset]);
}
}
$a = new Test;
$a[] = 'A'; // 0
$a[] = 10; // 1
$a[] = null; // 2
echo isset($a[0]) ? 'set' : 'unset', "\n";
echo isset($a[1]) ? 'set' : 'unset', "\n";
echo isset($a[2]) ? 'set' : 'unset', "\n";
Expected result:
set
set
unset
Actual result:
--
set
set
set
--
Edit this bug report at http://bugs.php.net/?id=41727&edit=1
#41727 [NEW]: ArrayAccess::offsetExists works wrong with isset()
From: dan at yes dot lt
Operating system: WinXP
PHP version: 5.2.3
PHP Bug Type: SPL related
Bug description: ArrayAccess::offsetExists works wrong with isset()
Description:
method ArrayAccess actualy works wrong with isset()/empty()...
isset()/empty() now calls only ArrayAccess::offsetExist, but should call
both ArrayAccess::offsetExist and ArrayAccess::offsetGet to check if value
is realy set.
that's how arrays do...
Reproduce code:
---
class Test implements ArrayAccess
{
protected $_array = array();
protected $_count = 0;
function offsetExists($offset)
{
return $offset >= 0 && $offset < $this->_count;
}
function offsetGet($offset)
{
return $this->_array[$offset];
}
function offsetSet($offset, $value)
{
$this->_array[] = $value;
$this->_count++;
}
function offsetUnset($offset)
{
unset($this->_array[$offset]);
}
}
$a = new Test;
$a[] = 'A'; // 0
$a[] = 10; // 1
$a[] = null; // 2
echo isset($a[0]) ? 'set' : 'unset', "\n";
echo isset($a[1]) ? 'set' : 'unset', "\n";
echo isset($a[2]) ? 'set' : 'unset', "\n";
Expected result:
set
set
unset
Actual result:
--
set
set
set
--
Edit bug report at http://bugs.php.net/?id=41727&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=41727&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=41727&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=41727&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=41727&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=41727&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=41727&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=41727&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=41727&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=41727&r=support
Expected behavior:http://bugs.php.net/fix.php?id=41727&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=41727&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=41727&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=41727&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41727&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=41727&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=41727&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=41727&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=41727&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=41727&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=41727&r=mysqlcfg
#34523 [NEW]: pdo drivers are not compiled due to compilation errors
From: dan at yes dot lt Operating system: windows PHP version: 5CVS-2005-09-16 (snap) PHP Bug Type: PDO related Bug description: pdo drivers are not compiled due to compilation errors Description: PDO drivers are not compiled due to compilation errors Some lines from http://snaps.php.net/win32/snapshot-5.1.log ext\pdo_dblib\dblib_driver.c(250) : error C2198: 'php_pdo_get_exception' : too few actual parameters ext\pdo_mysql\mysql_driver.c(100) : error C2198: 'php_pdo_get_exception' : too few actual parameters ext\pdo_oci\oci_driver.c(161) : error C2198: 'php_pdo_get_exception' : too few actual parameters ext\pdo_odbc\odbc_driver.c(90) : error C2198: 'php_pdo_get_exception' : too few actual parameters ext\pdo_pgsql\pgsql_driver.c(83) : error C2198: 'php_pdo_get_exception' : too few actual parameters ext\pdo_sqlite\sqlite_driver.c(78) : error C2198: 'php_pdo_get_exception' : too few actual parameters ext\pdo_sqlite\sqlite_driver.c(695) : error C2198: 'php_pdo_get_exception' : too few actual parameters -- Edit bug report at http://bugs.php.net/?id=34523&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34523&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=34523&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=34523&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=34523&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=34523&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=34523&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=34523&r=needscript Try newer version: http://bugs.php.net/fix.php?id=34523&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=34523&r=support Expected behavior: http://bugs.php.net/fix.php?id=34523&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=34523&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=34523&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=34523&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34523&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=34523&r=dst IIS Stability: http://bugs.php.net/fix.php?id=34523&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=34523&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=34523&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=34523&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=34523&r=mysqlcfg
#33109 [NEW]: no required wsyslog.h found in php sources
From: dan at yes dot lt Operating system: winxp PHP version: 5CVS-2005-05-23 (dev) PHP Bug Type: *General Issues Bug description: no required wsyslog.h found in php sources Description: no required wsyslog.h found in php sources, can't compile without it... -- Edit bug report at http://bugs.php.net/?id=33109&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33109&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33109&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33109&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33109&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33109&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33109&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33109&r=needscript Try newer version: http://bugs.php.net/fix.php?id=33109&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33109&r=support Expected behavior: http://bugs.php.net/fix.php?id=33109&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33109&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33109&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33109&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33109&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33109&r=dst IIS Stability: http://bugs.php.net/fix.php?id=33109&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33109&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33109&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33109&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33109&r=mysqlcfg
#33005 [Opn]: mysqli do not support float type
ID: 33005 User updated by: dan at yes dot lt Reported By: dan at yes dot lt Status: Open Bug Type: MySQLi related Operating System: winxp -PHP Version: 5CVS-2005-05-16 (dev) +PHP Version: 5CVS-2005-05-19 (dev) Assigned To: andrey New Comment: with libmysql.dll v4.1.7 crashes only with float "SELECT 1.23 ..." Previous Comments: [2005-05-19 12:56:55] [EMAIL PROTECTED] php_musqli.dll when compiled 4.1.7 headers afaik - therefore 4.1.7 libmysql.dll has to be used (afaik). [2005-05-16 08:52:27] dan at yes dot lt with new php_mysqli.dll script crashes near the "$st->fetch()" with any query (SELECT 1 ... , SELECT 1.23 ... , or SELECT 'x' ...). libmysql 5.0.4-beta ------------ [2005-05-13 11:00:23] dan at yes dot lt I've tried to update libmysql to 4.1.11 and to 5.0.4-beta - this wont help... Also - where can I get the newest php_mysqli.dll ? The latest builds are going without it - may be this is a problem ? [2005-05-12 21:33:25] [EMAIL PROTECTED] Cannot reproduce with PHP 5.1-dev, libmysql 4.1.12 and MySQL 5.0.6-beta. Can you try upgrading your client library? Thanks! ---------------- [2005-05-11 10:52:52] dan at yes dot lt PHP Version 5.0.5-dev MySQLi Client API version 4.1.7 MySQL Server version: 5.0.4-beta 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/33005 -- Edit this bug report at http://bugs.php.net/?id=33005&edit=1
#33005 [Opn]: mysqli do not support float type
ID: 33005
User updated by: dan at yes dot lt
Reported By: dan at yes dot lt
Status: Open
Bug Type: MySQLi related
Operating System: winxp
-PHP Version: 5CVS-2005-05-13 (dev)
+PHP Version: 5CVS-2005-05-16 (dev)
Assigned To: andrey
New Comment:
with new php_mysqli.dll script crashes near the "$st->fetch()" with any
query (SELECT 1 ... , SELECT 1.23 ... , or SELECT 'x' ...).
libmysql 5.0.4-beta
Previous Comments:
[2005-05-13 11:00:23] dan at yes dot lt
I've tried to update libmysql to 4.1.11 and to 5.0.4-beta - this wont
help... Also - where can I get the newest php_mysqli.dll ? The latest
builds are going without it - may be this is a problem ?
[2005-05-12 21:33:25] [EMAIL PROTECTED]
Cannot reproduce with PHP 5.1-dev, libmysql 4.1.12 and MySQL
5.0.6-beta.
Can you try upgrading your client library? Thanks!
----
[2005-05-11 10:52:52] dan at yes dot lt
PHP Version 5.0.5-dev
MySQLi Client API version 4.1.7
MySQL Server version: 5.0.4-beta
[2005-05-11 09:36:37] [EMAIL PROTECTED]
Can't reproduce
Connecting to MySQL 4.1 returns
int(1)
float(1.23)
Connectiong to MySQL 5.0 returns
int(1)
string(4) "1.23"
Which MySQL client library and server do you use?
--------------------
[2005-05-11 07:58:39] dan at yes dot lt
Description:
mysqli do not supports float type neither in results nor in params. for
result it returns NULL instead of float, for params there is no type
letter for float type...
Reproduce code:
---
$db = new mysqli(...);
$st = $db->prepare("SELECT 1.23 AS test");
$st->execute();
$st->store_result();
var_dump($st->num_rows);
$st->bind_result($x);
$st->fetch();
$st->free_result();
$st->close();
var_dump($x);
Expected result:
int(1)
float(1.23)
Actual result:
--
int(1)
NULL
--
Edit this bug report at http://bugs.php.net/?id=33005&edit=1
#33005 [Fbk->Opn]: mysqli do not support float type
ID: 33005
User updated by: dan at yes dot lt
Reported By: dan at yes dot lt
-Status: Feedback
+Status: Open
Bug Type: MySQLi related
Operating System: winxp
-PHP Version: 5CVS-2005-05-11 (dev)
+PHP Version: 5CVS-2005-05-13 (dev)
Assigned To: andrey
New Comment:
I've tried to update libmysql to 4.1.11 and to 5.0.4-beta - this wont
help... Also - where can I get the newest php_mysqli.dll ? The latest
builds are going without it - may be this is a problem ?
Previous Comments:
[2005-05-12 21:33:25] [EMAIL PROTECTED]
Cannot reproduce with PHP 5.1-dev, libmysql 4.1.12 and MySQL
5.0.6-beta.
Can you try upgrading your client library? Thanks!
[2005-05-11 10:52:52] dan at yes dot lt
PHP Version 5.0.5-dev
MySQLi Client API version 4.1.7
MySQL Server version: 5.0.4-beta
[2005-05-11 09:36:37] [EMAIL PROTECTED]
Can't reproduce
Connecting to MySQL 4.1 returns
int(1)
float(1.23)
Connectiong to MySQL 5.0 returns
int(1)
string(4) "1.23"
Which MySQL client library and server do you use?
[2005-05-11 07:58:39] dan at yes dot lt
Description:
mysqli do not supports float type neither in results nor in params. for
result it returns NULL instead of float, for params there is no type
letter for float type...
Reproduce code:
---
$db = new mysqli(...);
$st = $db->prepare("SELECT 1.23 AS test");
$st->execute();
$st->store_result();
var_dump($st->num_rows);
$st->bind_result($x);
$st->fetch();
$st->free_result();
$st->close();
var_dump($x);
Expected result:
int(1)
float(1.23)
Actual result:
--
int(1)
NULL
--
Edit this bug report at http://bugs.php.net/?id=33005&edit=1
#33005 [Fbk->Opn]: mysqli do not support float type
ID: 33005
User updated by: dan at yes dot lt
Reported By: dan at yes dot lt
-Status: Feedback
+Status: Open
Bug Type: MySQLi related
Operating System: winxp
PHP Version: 5CVS-2005-05-11 (dev)
New Comment:
PHP Version 5.0.5-dev
MySQLi Client API version 4.1.7
MySQL Server version: 5.0.4-beta
Previous Comments:
[2005-05-11 09:36:37] [EMAIL PROTECTED]
Can't reproduce
Connecting to MySQL 4.1 returns
int(1)
float(1.23)
Connectiong to MySQL 5.0 returns
int(1)
string(4) "1.23"
Which MySQL client library and server do you use?
[2005-05-11 07:58:39] dan at yes dot lt
Description:
mysqli do not supports float type neither in results nor in params. for
result it returns NULL instead of float, for params there is no type
letter for float type...
Reproduce code:
---
$db = new mysqli(...);
$st = $db->prepare("SELECT 1.23 AS test");
$st->execute();
$st->store_result();
var_dump($st->num_rows);
$st->bind_result($x);
$st->fetch();
$st->free_result();
$st->close();
var_dump($x);
Expected result:
int(1)
float(1.23)
Actual result:
--
int(1)
NULL
--
Edit this bug report at http://bugs.php.net/?id=33005&edit=1
#33005 [NEW]: mysqli do not support float type
From: dan at yes dot lt
Operating system: winxp
PHP version: 5CVS-2005-05-11 (dev)
PHP Bug Type: MySQLi related
Bug description: mysqli do not support float type
Description:
mysqli do not supports float type neither in results nor in params. for
result it returns NULL instead of float, for params there is no type
letter for float type...
Reproduce code:
---
$db = new mysqli(...);
$st = $db->prepare("SELECT 1.23 AS test");
$st->execute();
$st->store_result();
var_dump($st->num_rows);
$st->bind_result($x);
$st->fetch();
$st->free_result();
$st->close();
var_dump($x);
Expected result:
int(1)
float(1.23)
Actual result:
--
int(1)
NULL
--
Edit bug report at http://bugs.php.net/?id=33005&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33005&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=33005&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=33005&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33005&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33005&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=33005&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=33005&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=33005&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33005&r=support
Expected behavior: http://bugs.php.net/fix.php?id=33005&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=33005&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=33005&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33005&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33005&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33005&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=33005&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33005&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=33005&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=33005&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=33005&r=mysqlcfg
#32928 [Bgs->Opn]: php dies trying to ->bind_result(...)
ID: 32928
User updated by: dan at yes dot lt
Reported By: dan at yes dot lt
-Status: Bogus
+Status: Open
Bug Type: MySQLi related
Operating System: winxp
PHP Version: 5.0.4, 5.0.5-dev
Assigned To: georg
New Comment:
Still crashes for me with latest 5.0.5-dev... Just forgot to write
->execute() in sample.
MySQL version 5.0.4 - may be this is important.
// This works
$db = new mysqli(...);
$st = $db->prepare("SELECT 1 AS test");
$st->execute();
$st->bind_result($x);
$st->fetch();
var_dump($x);
// This crashes
$db = new mysqli(...);
$st = $db->prepare("SELECT 1.23 AS test");
$st->execute();
$st->bind_result($x);
$st->fetch();
var_dump($x);
// This crashes too
$db = new mysqli(...);
$st = $db->prepare("SELECT NULL AS test");
$st->execute();
$st->bind_result($x);
$st->fetch();
var_dump($x);
Previous Comments:
[2005-05-06 15:43:28] [EMAIL PROTECTED]
Doesn't crash here (tested against PHP-5.0.5-dev and PHP-5.1.0-dev) and
returns NULL as expected.
Please reread the documentation on how to work with prepared
statements. It makes no sense to fetch a value from a prepared
statement without executing it before.
--------------------
[2005-05-06 08:44:06] dan at yes dot lt
php also dies with latest snapshot
[2005-05-06 03:14:55] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.0-win32-latest.zip
--------------------
[2005-05-05 15:47:53] dan at yes dot lt
this is not NULL or unbuffered resultset only...
try this:
Reproduce code:
---
$st = $db->prepare("SELECT 1.23 AS test");
$st->bind_result($x);
$st->fetch();
var_dump($x);
Expected result:
float(1.23)
Actual result:
--
...FATAL ERROR WITH NO OUTPUT...
or maybe floats are also unsupported ?..
[2005-05-05 15:41: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
Prepared statements return unbuffered resultsets by default,
therefore you have to retrieve all data or close the resultset before
any command to the server.
The last statement doesn't work, cause MYSQL_TYPE_NULL is unsupported
(filed as bug #32956).
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/32928
--
Edit this bug report at http://bugs.php.net/?id=32928&edit=1
#32928 [Fbk->Opn]: php dies trying to ->bind_result(...)
ID: 32928
User updated by: dan at yes dot lt
Reported By: dan at yes dot lt
-Status: Feedback
+Status: Open
Bug Type: MySQLi related
Operating System: winxp
-PHP Version: 5.0.4
+PHP Version: 5.0.4, 5.0.5-dev
Assigned To: georg
New Comment:
php also dies with latest snapshot
Previous Comments:
[2005-05-06 03:14:55] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.0-win32-latest.zip
[2005-05-05 15:47:53] dan at yes dot lt
this is not NULL or unbuffered resultset only...
try this:
Reproduce code:
---
$st = $db->prepare("SELECT 1.23 AS test");
$st->bind_result($x);
$st->fetch();
var_dump($x);
Expected result:
float(1.23)
Actual result:
--
...FATAL ERROR WITH NO OUTPUT...
or maybe floats are also unsupported ?..
[2005-05-05 15:41: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
Prepared statements return unbuffered resultsets by default,
therefore you have to retrieve all data or close the resultset before
any command to the server.
The last statement doesn't work, cause MYSQL_TYPE_NULL is unsupported
(filed as bug #32956).
[2005-05-04 09:58:00] [EMAIL PROTECTED]
Looks like repreparing a statement without closing it
makes some problems -> assigned (tested against
5.0.5-beta)
The script itself works as expected - fetching a row
without executing statement before returns an error.
----
[2005-05-03 16:19:30] dan at yes dot lt
Description:
php dies trying to mysqli_stmt->bind_result(...) with listed queries:
SELECT 1.23 AS test
SELECT NULL AS test
php version 5.0.4, mysql version 5.0.4 beta
Reproduce code:
---
$st = $db->prepare("SELECT 1 AS test");
$st->bind_result($x);
$st->fetch();
var_dump($x);
$st = $db->prepare("SELECT 1.23 AS test");
$st->bind_result($x);
$st->fetch();
var_dump($x);
$st = $db->prepare("SELECT NULL AS test");
$st->bind_result($x);
$st->fetch();
echo $st;
var_dump($x);
Expected result:
int(1)
float(1.23)
NULL
Actual result:
--
int(1)
...FATAL ERROR WITH NO OUTPUT...
...FATAL ERROR WITH NO OUTPUT...
--
Edit this bug report at http://bugs.php.net/?id=32928&edit=1
#32928 [Bgs->Opn]: php dies trying to ->bind_result(...)
ID: 32928
User updated by: dan at yes dot lt
Reported By: dan at yes dot lt
-Status: Bogus
+Status: Open
Bug Type: MySQLi related
Operating System: winxp
PHP Version: 5.0.4
Assigned To: georg
New Comment:
this is not NULL or unbuffered resultset only...
try this:
Reproduce code:
---
$st = $db->prepare("SELECT 1.23 AS test");
$st->bind_result($x);
$st->fetch();
var_dump($x);
Expected result:
float(1.23)
Actual result:
--
...FATAL ERROR WITH NO OUTPUT...
or maybe floats are also unsupported ?..
Previous Comments:
[2005-05-05 15:41: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
Prepared statements return unbuffered resultsets by default,
therefore you have to retrieve all data or close the resultset before
any command to the server.
The last statement doesn't work, cause MYSQL_TYPE_NULL is unsupported
(filed as bug #32956).
[2005-05-04 09:58:00] [EMAIL PROTECTED]
Looks like repreparing a statement without closing it
makes some problems -> assigned (tested against
5.0.5-beta)
The script itself works as expected - fetching a row
without executing statement before returns an error.
----
[2005-05-03 16:19:30] dan at yes dot lt
Description:
php dies trying to mysqli_stmt->bind_result(...) with listed queries:
SELECT 1.23 AS test
SELECT NULL AS test
php version 5.0.4, mysql version 5.0.4 beta
Reproduce code:
---
$st = $db->prepare("SELECT 1 AS test");
$st->bind_result($x);
$st->fetch();
var_dump($x);
$st = $db->prepare("SELECT 1.23 AS test");
$st->bind_result($x);
$st->fetch();
var_dump($x);
$st = $db->prepare("SELECT NULL AS test");
$st->bind_result($x);
$st->fetch();
echo $st;
var_dump($x);
Expected result:
int(1)
float(1.23)
NULL
Actual result:
--
int(1)
...FATAL ERROR WITH NO OUTPUT...
...FATAL ERROR WITH NO OUTPUT...
--
Edit this bug report at http://bugs.php.net/?id=32928&edit=1
#32928 [NEW]: php dies trying to ->bind_result(...)
From: dan at yes dot lt
Operating system: winxp
PHP version: 5.0.4
PHP Bug Type: MySQLi related
Bug description: php dies trying to ->bind_result(...)
Description:
php dies trying to mysqli_stmt->bind_result(...) with listed queries:
SELECT 1.23 AS test
SELECT NULL AS test
php version 5.0.4, mysql version 5.0.4 beta
Reproduce code:
---
$st = $db->prepare("SELECT 1 AS test");
$st->bind_result($x);
$st->fetch();
var_dump($x);
$st = $db->prepare("SELECT 1.23 AS test");
$st->bind_result($x);
$st->fetch();
var_dump($x);
$st = $db->prepare("SELECT NULL AS test");
$st->bind_result($x);
$st->fetch();
echo $st;
var_dump($x);
Expected result:
int(1)
float(1.23)
NULL
Actual result:
--
int(1)
...FATAL ERROR WITH NO OUTPUT...
...FATAL ERROR WITH NO OUTPUT...
--
Edit bug report at http://bugs.php.net/?id=32928&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32928&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=32928&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=32928&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=32928&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=32928&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=32928&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=32928&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=32928&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=32928&r=support
Expected behavior: http://bugs.php.net/fix.php?id=32928&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=32928&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=32928&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=32928&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32928&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=32928&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=32928&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=32928&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=32928&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=32928&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=32928&r=mysqlcfg
#32909 [NEW]: wddx_* works incorrectly with objects with private/protected members
From: dan at yes dot lt
Operating system: winxp
PHP version: 5.0.4
PHP Bug Type: WDDX related
Bug description: wddx_* works incorrectly with objects with private/protected
members
Description:
wddx_* works incorrectly with objects with private/protected members. for
correct behaviour see serialize/unserialize functions.
Reproduce code:
---
class Test
{
private $a = 10;
protected $b = true;
public $c = 'test';
}
$src = new Test();
print_r($src);
$wddx = wddx_serialize_value($src);
echo $wddx, "\n";
$dst = wddx_deserialize($wddx);
print_r($dst);
Expected result:
Test Object
(
[a:private] => 10
[b:protected] => 1
[c] => test
)
Test10test
Test Object
(
[a:private] => 10
[b:protected] => 1
[c] => test
)
Actual result:
--
Test Object
(
[a:private] => 10
[b:protected] => 1
[c] => test
)
Test10test
Test Object
(
[a:private] => 10
[b:protected] => 1
[c] => test
[0] => 10
[1] => 1
)
--
Edit bug report at http://bugs.php.net/?id=32909&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32909&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=32909&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=32909&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=32909&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=32909&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=32909&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=32909&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=32909&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=32909&r=support
Expected behavior: http://bugs.php.net/fix.php?id=32909&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=32909&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=32909&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=32909&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32909&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=32909&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=32909&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=32909&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=32909&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=32909&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=32909&r=mysqlcfg
#32865 [Bgs->Opn]: explode do not works with $limit = null
ID: 32865
User updated by: dan at yes dot lt
Reported By: dan at yes dot lt
-Status: Bogus
+Status: Open
Bug Type: Strings related
Operating System: WinXP
PHP Version: 5.0.4
New Comment:
now I have to write..
if ($lim === null) {
$parts = explode(',', $str);
} else {
$parts = explode(',', $str, $lim);
}
..instead of..
$parts = explode(',', $str, $lim);
Isn't it some sort of crap ?..
Previous Comments:
------------
[2005-04-28 12:09:12] dan at yes dot lt
So what should I give to $limit to explode unlimited ???... As I know -
in PHP no parameter means some default value - what default value is
defined to default $limit ?..
[2005-04-28 11:43:01] [EMAIL PROTECTED]
Yes, null == 0. (PHP is still loose typed language..)
------------
[2005-04-28 11:19:04] dan at yes dot lt
Description:
explode() do not explodes string if $limit argument is null, but
explodes if no $limit argument given.
Reproduce code:
---
print_r(explode(',', 'a,b,c'));
print_r(explode(',', 'a,b,c', null));
Expected result:
Array
(
[0] => a
[1] => b
[2] => c
)
Array
(
[0] => a
[1] => b
[2] => c
)
Actual result:
--
Array
(
[0] => a
[1] => b
[2] => c
)
Array
(
[0] => a,b,c
)
--
Edit this bug report at http://bugs.php.net/?id=32865&edit=1
#32865 [Bgs]: explode do not works with $limit = null
ID: 32865
User updated by: dan at yes dot lt
Reported By: dan at yes dot lt
Status: Bogus
Bug Type: Strings related
Operating System: WinXP
PHP Version: 5.0.4
New Comment:
So what should I give to $limit to explode unlimited ???... As I know -
in PHP no parameter means some default value - what default value is
defined to default $limit ?..
Previous Comments:
[2005-04-28 11:43:01] [EMAIL PROTECTED]
Yes, null == 0. (PHP is still loose typed language..)
[2005-04-28 11:19:04] dan at yes dot lt
Description:
explode() do not explodes string if $limit argument is null, but
explodes if no $limit argument given.
Reproduce code:
---
print_r(explode(',', 'a,b,c'));
print_r(explode(',', 'a,b,c', null));
Expected result:
Array
(
[0] => a
[1] => b
[2] => c
)
Array
(
[0] => a
[1] => b
[2] => c
)
Actual result:
--
Array
(
[0] => a
[1] => b
[2] => c
)
Array
(
[0] => a,b,c
)
--
Edit this bug report at http://bugs.php.net/?id=32865&edit=1
#32865 [NEW]: explode do not works with $limit = null
From: dan at yes dot lt
Operating system: WinXP
PHP version: 5.0.4
PHP Bug Type: *General Issues
Bug description: explode do not works with $limit = null
Description:
explode() do not explodes string if $limit argument is null, but explodes
if no $limit argument given.
Reproduce code:
---
print_r(explode(',', 'a,b,c'));
print_r(explode(',', 'a,b,c', null));
Expected result:
Array
(
[0] => a
[1] => b
[2] => c
)
Array
(
[0] => a
[1] => b
[2] => c
)
Actual result:
--
Array
(
[0] => a
[1] => b
[2] => c
)
Array
(
[0] => a,b,c
)
--
Edit bug report at http://bugs.php.net/?id=32865&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32865&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=32865&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=32865&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=32865&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=32865&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=32865&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=32865&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=32865&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=32865&r=support
Expected behavior: http://bugs.php.net/fix.php?id=32865&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=32865&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=32865&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=32865&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32865&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=32865&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=32865&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=32865&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=32865&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=32865&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=32865&r=mysqlcfg
#31512 [Bgs->Opn]: wrong expression execution order
ID: 31512 User updated by: dan at yes dot lt Reported By: dan at yes dot lt -Status: Bogus +Status: Open Bug Type: *General Issues Operating System: any PHP Version: 4.3.10 New Comment: it works if there is no $b =&$a reference, and fails, if there is that reference... Previous Comments: [2005-01-12 13:01:21] [EMAIL PROTECTED] Submitted twice. [2005-01-12 11:57:44] dan at yes dot lt Description: Arithmetic expression execution returns unexpected results with ++ or -- operators. Reproduce code: --- $a = 10; $c = $a++ + ++$a; echo "$c\n"; $a = 10; $c = ++$a + $a++; echo "$c\n"; Expected result: 22 22 Actual result: -- 22 23 <- ?? Why ?? -- Edit this bug report at http://bugs.php.net/?id=31512&edit=1
#31513 [Opn]: wrong expression execution order
ID: 31513 User updated by: dan at yes dot lt Reported By: dan at yes dot lt Status: Open Bug Type: *General Issues Operating System: any PHP Version: 5.0.3 New Comment: it works if there is no $b =&$a reference, and fails, if there is that reference... Previous Comments: [2005-01-12 13:17:38] dan at yes dot lt [2005-01-12 12:53:28] [EMAIL PROTECTED] You can never rely on this behavior, not in any language that I know about. Do not use the post/pre inc operation in assignments like this. [2005-01-12 11:58:30] dan at yes dot lt Description: Arithmetic expression execution returns unexpected results with ++ or -- operators. Reproduce code: --- $a = 10; $c = $a++ + ++$a; echo "$c\n"; $a = 10; $c = ++$a + $a++; echo "$c\n"; Expected result: 22 22 Actual result: -- 22 23 <- ?? Why ?? -- Edit this bug report at http://bugs.php.net/?id=31513&edit=1
#31513 [Bgs->Opn]: wrong expression execution order
ID: 31513 User updated by: dan at yes dot lt Reported By: dan at yes dot lt -Status: Bogus +Status: Open Bug Type: *General Issues Operating System: any PHP Version: 5.0.3 New Comment: Previous Comments: [2005-01-12 12:53:28] [EMAIL PROTECTED] You can never rely on this behavior, not in any language that I know about. Do not use the post/pre inc operation in assignments like this. [2005-01-12 11:58:30] dan at yes dot lt Description: Arithmetic expression execution returns unexpected results with ++ or -- operators. Reproduce code: --- $a = 10; $c = $a++ + ++$a; echo "$c\n"; $a = 10; $c = ++$a + $a++; echo "$c\n"; Expected result: 22 22 Actual result: -- 22 23 <- ?? Why ?? -- Edit this bug report at http://bugs.php.net/?id=31513&edit=1
#31512 [NEW]: wrong expression execution order
From: dan at yes dot lt Operating system: any PHP version: 4.3.10 PHP Bug Type: *General Issues Bug description: wrong expression execution order Description: Arithmetic expression execution returns unexpected results with ++ or -- operators. Reproduce code: --- $a = 10; $c = $a++ + ++$a; echo "$c\n"; $a = 10; $c = ++$a + $a++; echo "$c\n"; Expected result: 22 22 Actual result: -- 22 23 <- ?? Why ?? -- Edit bug report at http://bugs.php.net/?id=31512&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=31512&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=31512&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=31512&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=31512&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=31512&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=31512&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=31512&r=needscript Try newer version: http://bugs.php.net/fix.php?id=31512&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=31512&r=support Expected behavior: http://bugs.php.net/fix.php?id=31512&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=31512&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=31512&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=31512&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=31512&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=31512&r=dst IIS Stability: http://bugs.php.net/fix.php?id=31512&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=31512&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=31512&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=31512&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=31512&r=mysqlcfg
#31513 [NEW]: wrong expression execution order
From: dan at yes dot lt Operating system: any PHP version: 5.0.3 PHP Bug Type: *General Issues Bug description: wrong expression execution order Description: Arithmetic expression execution returns unexpected results with ++ or -- operators. Reproduce code: --- $a = 10; $c = $a++ + ++$a; echo "$c\n"; $a = 10; $c = ++$a + $a++; echo "$c\n"; Expected result: 22 22 Actual result: -- 22 23 <- ?? Why ?? -- Edit bug report at http://bugs.php.net/?id=31513&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=31513&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=31513&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=31513&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=31513&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=31513&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=31513&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=31513&r=needscript Try newer version: http://bugs.php.net/fix.php?id=31513&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=31513&r=support Expected behavior: http://bugs.php.net/fix.php?id=31513&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=31513&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=31513&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=31513&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=31513&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=31513&r=dst IIS Stability: http://bugs.php.net/fix.php?id=31513&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=31513&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=31513&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=31513&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=31513&r=mysqlcfg
#30656 [NEW]: mysqli_prepare returns "Unknown command"
From: dan at yes dot lt
Operating system: Windows 2000
PHP version: 5.0.2
PHP Bug Type: MySQLi related
Bug description: mysqli_prepare returns "Unknown command"
Description:
mysqli_prepare() and mysqli->prepare() returns "Unknown command" error.
I have tryed that with MySQL versions 4.1.5, 5.0.0a and 5.0.1. The result
was just the same.
Reproduce code:
---
$db = new mysqli(HOSTNAME, USERNAME, PASSWORD, DATABASE);
$st = $db->prepare("SELECT id, name FROM test WHERE name = ?");
if (!$st) echo $db->error; // "Unknown command"
--
Edit bug report at http://bugs.php.net/?id=30656&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=30656&r=trysnapshot4
Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=30656&r=trysnapshot50
Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=30656&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=30656&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=30656&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=30656&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=30656&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=30656&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=30656&r=support
Expected behavior: http://bugs.php.net/fix.php?id=30656&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=30656&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=30656&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=30656&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=30656&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=30656&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=30656&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=30656&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=30656&r=float
MySQL Configuration Error: http://bugs.php.net/fix.php?id=30656&r=mysqlcfg
#24428 [NEW]: no mysql
From: dan at yes dot lt Operating system: win PHP version: 5.0.0b1 (beta1) PHP Bug Type: *General Issues Bug description: no mysql Description: There is no MySQL support in PHP 5 ? PHP reports: Fatal error: Call to undefined function: mysql_connect() in ... Reproduce code: --- Expected result: :) connection to db Actual result: -- Fatal error: Call to undefined function: mysql_connect() in ... -- Edit bug report at http://bugs.php.net/?id=24428&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=24428&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=24428&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=24428&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=24428&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=24428&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=24428&r=support Expected behavior: http://bugs.php.net/fix.php?id=24428&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=24428&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=24428&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=24428&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24428&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=24428&r=dst IIS Stability: http://bugs.php.net/fix.php?id=24428&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=24428&r=gnused
