Bug #54547 [Com]: wrong equality of string numbers
Edit report at https://bugs.php.net/bug.php?id=54547&edit=1 ID: 54547 Comment by: chx1975 at gmail dot com Reported by:peter dot ritt at gmx dot net Summary:wrong equality of string numbers Status: Verified Type: Bug Package:Unknown/Other Function Operating System: linux PHP Version:5.3.6 Assigned To:dmitry Block user comment: N Private report: N New Comment: Now, while I can understand why PHP chooses "1" == 1 (HTML, sure) I am not too sure how is that relevant when both sides are strings?? I am not quite sure why the strings "1" and "1.0" would need to be ==. Just because "1" == 1 and "1.0" == 1 does not mean "1" == "1.0". It's not transitive! Compare FALSE == 0; 0 == 'x'; 'x' == TRUE -- if it would be transitive then FALSE == TRUE, surely you don't want that. Previous Comments: [2012-04-12 21:23:40] vinny_182 at hotmail dot com Equality is equality and neither string or numeric representations of the value are equal. The bug IMO is in the conversion from string to float, the conversion has failed but a valid value is still returned. That's just plain wrong. If you wrote unit tests for string to float conversions and this was the input you would expect it to return a null value or throw an exception. [2012-04-12 21:02:06] c at hotmail dot com "In the majority of cases when dealing with HTTP requests and database results, which is what PHP deals with most, the loose comparison makes life easiest on the developer." By 'the developer' I assume you mean people who can't type (string) or (int) ? No other language has this issue because they aren't designed around programmers who do not really understand how to program. Please make the developer's life easier by making comparisons make sense. [2012-04-12 20:38:48] elementation at gmail dot com It's absolutely unreal that this is even a discussion. PHP, the world doesn't take you seriously and with bugs like this you provide further fodder. Principle of Least Surprise â this should be a string comparison. [2012-04-12 20:32:57] b at hotmail dot vom I would like to point out Perl is a weakly typed language, just like PHP, and has no issue with these cases. It's pretty weak from the developers to hide behind the "But PHP is weakly typed!" argument. [2012-04-12 17:09:41] riel at surriel dot com Conversion of numeric-looking strings to numbers does not have to be a problem, as long as the code in the back end uses arbitrary-precision math. This is slower than comparing a type that fits in a CPU register, but once you have already spent the time to do an automatic type conversion, that really does not matter. When it comes to an operator like ==, every digit matters. Having == return false when two items are different violates the principle of least surprise. 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 https://bugs.php.net/bug.php?id=54547 -- Edit this bug report at https://bugs.php.net/bug.php?id=54547&edit=1
#44135 [Com]: PDO MySQL does not support CLIENT_FOUND_ROWS
ID: 44135 Comment by: chx1975 at gmail dot com Reported By: chx1975 at gmail dot com Status: To be documented Bug Type: PDO related Operating System: Linux PHP Version: 5.2.5 Assigned To: johannes New Comment: So dropping a feature found in both older SQL drivers is not considered a bug? Previous Comments: [2009-10-02 19:59:20] u...@php.net It is in 5.3+ and not in 5.2 because its a new feature. [2009-10-02 19:48:50] lordbyron at sogetthis dot com Still doesn't exist in 5.2.11, nor does something which would accomplish the same goal. [2009-09-22 01:17:25] sadrak at sogetthis dot com Verified this constant still does not exist in php 5.2.10. [2009-08-05 18:54:26] lordbyron at sogetthis dot com Bug still occurs in php 5.2.9, on 64 bit linux. Appears that constant PDO::MYSQL_ATTR_FOUND_ROWS was not added to this version or removed as PDO driver does not recognize it. [2009-02-21 23:48:51] kamazee at gmail dot com This issue is still actual for stable releases _after_ the PHP 5.2.5 (tested 5.2.6 for Linux and 5.2.8 for Windows). Hope, changes will appear in stable branch soon. 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/44135 -- Edit this bug report at http://bugs.php.net/?id=44135&edit=1
#41135 [Com]: PDO SQLite BLOB field data truncated after 21 bytes
ID: 41135
Comment by: chx1975 at gmail dot com
Reported By: rich at corephp dot co dot uk
Status: Assigned
Bug Type: PDO related
Operating System: Windows XP SP2
PHP Version: 5.2.1
Assigned To: wez
New Comment:
I just ran Wez's test code and got 006100 so it seems I am unable to
reproduce this bug. PECL Module version => 1.0.1 $Id: pdo_sqlite.c,v
1.10.2.6.2.2 2007/03/23 14:30:00 wez Exp $
SQLite library => 3.4.2
Previous Comments:
[2008-01-22 17:21:34] maciej dot pijanka at gmail dot com
on linux, with php 5.2.5 and postgresql 8.2.5, problem is replicable
ie after last example table gets empty '' values not NULLs. I wrote
more detailed testcase.
-- file.php --
getMessage();
exit;
}
$binarydata = "abcdefg\x00a\x00\x01\x02";
$db->exec('CREATE TABLE test (data bytea, comment varchar(64), len
integer)');
$stmt = $db->prepare("INSERT INTO test VALUES ( :data, :comment, :len
)");
# test 1, just binary data, will fail
$comment = 'Just pass binary data as bindValue';
$stmt->bindValue('data', $binarydata);
$stmt->bindValue('comment', $comment); $stmt->bindValue('len',
strlen($binarydata));
var_dump($stmt->execute(), $stmt->rowCount(), $comment); print "--\n";
# pass as bindParam
$comment = 'Just pass binary data as bindParam';
$stmt->bindParam('data', &$binarydata);
$stmt->bindValue('comment', $comment); $stmt->bindValue('len',
strlen($binarydata));
var_dump($stmt->execute(), $stmt->rowCount(), $comment); print "--\n";
# encoded by pg_escape_bytea, wrong too
$comment = 'encoded by pg_escape_bytea';
$stmt->bindValue('data', pg_escape_bytea($binarydata));
$stmt->bindValue('comment', $comment); $stmt->bindValue('len',
strlen($binarydata));
var_dump($stmt->execute(), $stmt->rowCount(), $comment); print "--\n";
# pass something that give correct result
$comment = 'this one produces best result so far';
$stmt->bindValue('data',
str_replace("","\\",pg_escape_bytea($binarydata)),PDO::PARAM_STR);
$stmt->bindValue('comment', $comment); $stmt->bindValue('len',
strlen($binarydata));
var_dump($stmt->execute(), $stmt->rowCount(), $comment); print "--\n";
echo " NOW FETCH \nExecute returned: ";
$stmt = $db->prepare("select * from test");
var_dump($stmt->execute());
# with or without that its still wrong
#$db->setAttribute(PDO::ATTR_STRINGIFY_FETCHES,true);
print "\nFetching and comparing data\n";
# with fetchall resources don't work too
while($row = $stmt->fetch(PDO::FETCH_ASSOC)) {
$buffer = '';
#var_dump($row);
if(is_resource($row['data'])) {
$buffer = stream_get_contents($row['data']);
} else
$buffer = $row['data'];
print "Test `".$row['comment']."' StrCmp:";
print "".(strcmp($binarydata,$buffer) == 0 )?"equal":"fail";
print " length stored in db: ". $row['len'] . ", returned data
len: ".strlen($buffer)."\n";
echo bin2hex($buffer)."\n";
}
$db->exec('DROP TABLE test');
?>
== end of file ===
and output for me looks like
(only rows with results)
Fetching and comparing data
Test `Just pass binary data as bindValue' StrCmp:fail length stored in
db: 12, returned data len: 7
61626364656667
Test `Just pass binary data as bindParam' StrCmp:fail length stored in
db: 12, returned data len: 7
61626364656667
Test `encoded by pg_escape_bytea' StrCmp:fail length stored in db: 12,
returned data len: 24
616263646566675c303030615c3030305c3030315c303032
Test `this one produces best result so far' StrCmp:equal length stored
in db: 12, returned data len: 12
616263646566670061000102
[2007-04-21 03:28:18] [EMAIL PROTECTED]
What does the following script output for you?
$db->exec('CREATE TABLE test (data blob)');
$stmt = $db->prepare("INSERT INTO test VALUES ( ? )");
$stmt->bindParam(1, $name);
$name = "\x00a\x00";
var_dump($stmt->execute(), $stmt->rowCount());
$stmt = $db->prepare("select * from test");
var_dump($stmt->execute());
foreach ($stmt->fetchAll() as $row) {
echo bin2hex($row[0]), "\n";
}
[2007-04-20 18:0
#41135 [Com]: PDO SQLite BLOB field data truncated after 21 bytes
ID: 41135
Comment by: chx1975 at gmail dot com
Reported By: rich at corephp dot co dot uk
Status: Assigned
Bug Type: PDO related
Operating System: Windows XP SP2
PHP Version: 5.2.1
Assigned To: wez
New Comment:
Based on
http://netevil.org/blog/2005/oct/lob-support-added-to-pdo-oci-in-php-5-1-cvs-finally
I believe maciej dot pijanka at gmail dot com wants this code:
$db = new PDO(...);
$binarydata = "abcdefg\x00a\x00\x01\x02";
$db->exec('CREATE TABLE test (data bytea, comment varchar(64), len
integer)');
$db->beginTransaction();
$a = tempnam('.', 'pdo');
file_put_contents($a, $binarydata);
$stmt = $db->prepare("INSERT INTO test (data, comment, len) VALUES
(:data, :comment, :len)");
$stmt->bindParam(':data', $blob, PDO::PARAM_LOB);
$comment = 'lob';
$stmt->bindParam(':comment', $comment);
$len = filesize($a);
$stmt->bindParam(':len', $len);
$blob = fopen($a, 'rb');
$stmt->execute();
$db->commit();
unlink($a);
print "\nFetching and comparing data\n";
# with fetchall resources don't work too
$stmt = $db->prepare("select * from test");
$stmt->execute();
$db->setAttribute(PDO::ATTR_STRINGIFY_FETCHES,true);
while($row = $stmt->fetch(PDO::FETCH_ASSOC)) {
$buffer = '';
var_dump($row);
if(is_resource($row['data'])) {
$buffer = stream_get_contents($row['data']);
} else
$buffer = $row['data'];
print "Test `".$row['comment']."' StrCmp:";
print "".(strcmp($binarydata,$buffer) == 0 )?"equal":"fail";
print " length stored in db: ". $row['len'] . ", returned data
len: ".strlen($buffer)."\n";
echo bin2hex($buffer)."\n";
}
$db->exec('DROP TABLE test');
Previous Comments:
[2008-02-03 20:43:34] chx1975 at gmail dot com
I just ran Wez's test code and got 006100 so it seems I am unable to
reproduce this bug. PECL Module version => 1.0.1 $Id: pdo_sqlite.c,v
1.10.2.6.2.2 2007/03/23 14:30:00 wez Exp $
SQLite library => 3.4.2
[2008-01-22 17:21:34] maciej dot pijanka at gmail dot com
on linux, with php 5.2.5 and postgresql 8.2.5, problem is replicable
ie after last example table gets empty '' values not NULLs. I wrote
more detailed testcase.
-- file.php --
getMessage();
exit;
}
$binarydata = "abcdefg\x00a\x00\x01\x02";
$db->exec('CREATE TABLE test (data bytea, comment varchar(64), len
integer)');
$stmt = $db->prepare("INSERT INTO test VALUES ( :data, :comment, :len
)");
# test 1, just binary data, will fail
$comment = 'Just pass binary data as bindValue';
$stmt->bindValue('data', $binarydata);
$stmt->bindValue('comment', $comment); $stmt->bindValue('len',
strlen($binarydata));
var_dump($stmt->execute(), $stmt->rowCount(), $comment); print "--\n";
# pass as bindParam
$comment = 'Just pass binary data as bindParam';
$stmt->bindParam('data', &$binarydata);
$stmt->bindValue('comment', $comment); $stmt->bindValue('len',
strlen($binarydata));
var_dump($stmt->execute(), $stmt->rowCount(), $comment); print "--\n";
# encoded by pg_escape_bytea, wrong too
$comment = 'encoded by pg_escape_bytea';
$stmt->bindValue('data', pg_escape_bytea($binarydata));
$stmt->bindValue('comment', $comment); $stmt->bindValue('len',
strlen($binarydata));
var_dump($stmt->execute(), $stmt->rowCount(), $comment); print "--\n";
# pass something that give correct result
$comment = 'this one produces best result so far';
$stmt->bindValue('data',
str_replace("","\\",pg_escape_bytea($binarydata)),PDO::PARAM_STR);
$stmt->bindValue('comment', $comment); $stmt->bindValue('len',
strlen($binarydata));
var_dump($stmt->execute(), $stmt->rowCount(), $comment); print "--\n";
echo " NOW FETCH \nExecute returned: ";
$stmt = $db->prepare("select * from test");
var_dump($stmt->execute());
# with or without that its still wrong
#$db->setAttribute(PDO::ATTR_STRINGIFY_FETCHES,true);
print "\nFetching and comparing data\n";
# with fetchall resources don't work too
while($row = $stmt->fetch(PDO::FETCH_ASSOC)) {
$buffer = '';
#var_dump($row);
if(is_resource($row['data'])) {
$buf
#41135 [Com]: PDO SQLite BLOB field data truncated after 21 bytes
ID: 41135
Comment by: chx1975 at gmail dot com
Reported By: rich at corephp dot co dot uk
Status: Assigned
Bug Type: PDO related
Operating System: Windows XP SP2
PHP Version: 5.2.1
Assigned To: wez
New Comment:
My final note here is that you can avoid a temporary file with the
php://memory stream.
$stmt->bindParam(':data', $blob, PDO::PARAM_LOB);
$stmt->bindParam(':len', $len);
$blob = fopen('php://memory', 'a');
$len = fwrite($blob, $binarydata);
rewind($blob);
Previous Comments:
----------------
[2008-02-03 22:33:33] chx1975 at gmail dot com
Based on
http://netevil.org/blog/2005/oct/lob-support-added-to-pdo-oci-in-php-5-1-cvs-finally
I believe maciej dot pijanka at gmail dot com wants this code:
$db = new PDO(...);
$binarydata = "abcdefg\x00a\x00\x01\x02";
$db->exec('CREATE TABLE test (data bytea, comment varchar(64), len
integer)');
$db->beginTransaction();
$a = tempnam('.', 'pdo');
file_put_contents($a, $binarydata);
$stmt = $db->prepare("INSERT INTO test (data, comment, len) VALUES
(:data, :comment, :len)");
$stmt->bindParam(':data', $blob, PDO::PARAM_LOB);
$comment = 'lob';
$stmt->bindParam(':comment', $comment);
$len = filesize($a);
$stmt->bindParam(':len', $len);
$blob = fopen($a, 'rb');
$stmt->execute();
$db->commit();
unlink($a);
print "\nFetching and comparing data\n";
# with fetchall resources don't work too
$stmt = $db->prepare("select * from test");
$stmt->execute();
$db->setAttribute(PDO::ATTR_STRINGIFY_FETCHES,true);
while($row = $stmt->fetch(PDO::FETCH_ASSOC)) {
$buffer = '';
var_dump($row);
if(is_resource($row['data'])) {
$buffer = stream_get_contents($row['data']);
} else
$buffer = $row['data'];
print "Test `".$row['comment']."' StrCmp:";
print "".(strcmp($binarydata,$buffer) == 0 )?"equal":"fail";
print " length stored in db: ". $row['len'] . ", returned data
len: ".strlen($buffer)."\n";
echo bin2hex($buffer)."\n";
}
$db->exec('DROP TABLE test');
[2008-02-03 20:43:34] chx1975 at gmail dot com
I just ran Wez's test code and got 006100 so it seems I am unable to
reproduce this bug. PECL Module version => 1.0.1 $Id: pdo_sqlite.c,v
1.10.2.6.2.2 2007/03/23 14:30:00 wez Exp $
SQLite library => 3.4.2
[2008-01-22 17:21:34] maciej dot pijanka at gmail dot com
on linux, with php 5.2.5 and postgresql 8.2.5, problem is replicable
ie after last example table gets empty '' values not NULLs. I wrote
more detailed testcase.
-- file.php --
getMessage();
exit;
}
$binarydata = "abcdefg\x00a\x00\x01\x02";
$db->exec('CREATE TABLE test (data bytea, comment varchar(64), len
integer)');
$stmt = $db->prepare("INSERT INTO test VALUES ( :data, :comment, :len
)");
# test 1, just binary data, will fail
$comment = 'Just pass binary data as bindValue';
$stmt->bindValue('data', $binarydata);
$stmt->bindValue('comment', $comment); $stmt->bindValue('len',
strlen($binarydata));
var_dump($stmt->execute(), $stmt->rowCount(), $comment); print "--\n";
# pass as bindParam
$comment = 'Just pass binary data as bindParam';
$stmt->bindParam('data', &$binarydata);
$stmt->bindValue('comment', $comment); $stmt->bindValue('len',
strlen($binarydata));
var_dump($stmt->execute(), $stmt->rowCount(), $comment); print "--\n";
# encoded by pg_escape_bytea, wrong too
$comment = 'encoded by pg_escape_bytea';
$stmt->bindValue('data', pg_escape_bytea($binarydata));
$stmt->bindValue('comment', $comment); $stmt->bindValue('len',
strlen($binarydata));
var_dump($stmt->execute(), $stmt->rowCount(), $comment); print "--\n";
# pass something that give correct result
$comment = 'this one produces best result so far';
$stmt->bindValue('data',
str_replace("","\\",pg_escape_bytea($binarydata)),PDO::PARAM_STR);
$stmt->bindValue('comment', $comment); $stmt->bindValue('len',
strlen($binarydata));
var_dump($stmt->execute(), $stmt->rowCount(), $comment); print "--\n";
echo " NOW FETCH \nExecute returned: ";
$stmt = $db->prepare("select * fr
#44135 [NEW]: PDO MySQL does not support CLIENT_FOUND_ROWS
From: chx1975 at gmail dot com Operating system: Linux PHP version: 5.2.5 PHP Bug Type: PDO related Bug description: PDO MySQL does not support CLIENT_FOUND_ROWS Description: mysql_real_connect supports client flags http://dev.mysql.com/doc/refman/4.1/en/mysql-real-connect.html most importantly CLIENT_FOUND_ROWS but PDO provides no way to pass it in. -- Edit bug report at http://bugs.php.net/?id=44135&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=44135&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=44135&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=44135&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=44135&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=44135&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=44135&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=44135&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=44135&r=needscript Try newer version:http://bugs.php.net/fix.php?id=44135&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=44135&r=support Expected behavior:http://bugs.php.net/fix.php?id=44135&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=44135&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=44135&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=44135&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=44135&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=44135&r=dst IIS Stability:http://bugs.php.net/fix.php?id=44135&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=44135&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=44135&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=44135&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=44135&r=mysqlcfg
#44135 [Com]: PDO MySQL does not support CLIENT_FOUND_ROWS
ID: 44135
Comment by: chx1975 at gmail dot com
Reported By: chx1975 at gmail dot com
Status: Open
Bug Type: PDO related
Operating System: Linux
PHP Version: 5.2.5
New Comment:
An attempt to fix this can be found at
http://drupal4hu.com/php-44135.patch . I added a number of flags not
just the one I needed.
running
PDO::MYSQL_CLIENT_FOUND_ROWS));
$p->exec('TRUNCATE a');
$p->exec('INSERT INTO a VALUES (1)');
echo $p->exec('UPDATE a SET a = 1 WHERE a = 1');
$p = new PDO('mysql:host=localhost;dbname=test', 'root', '');
echo $p->exec('UPDATE a SET a = 1 WHERE a = 1');
?>
shows a 1 (one row found) and then a 0 (0 updated) so the patch seems
to work.
Previous Comments:
[2008-02-16 03:29:44] larry at garfieldtech dot com
I can duplicate this problem. The issue appears to be that by
default, MySQL will return the number of affected rows from a
previous UPDATE statement, not the number of matched rows. That
values will differ if the update statement would set a row to its
existing value. With ext/mysql and ext/mysqli, it can be set to
return matched rows instead. PDO does not appear to have a way to
allow that.
--------------------
[2008-02-16 03:26:34] chx1975 at gmail dot com
Description:
mysql_real_connect supports client flags
http://dev.mysql.com/doc/refman/4.1/en/mysql-real-connect.html most
importantly CLIENT_FOUND_ROWS but PDO provides no way to pass it in.
--
Edit this bug report at http://bugs.php.net/?id=44135&edit=1
#44135 [Com]: PDO MySQL does not support CLIENT_FOUND_ROWS
ID: 44135
Comment by: chx1975 at gmail dot com
Reported By: chx1975 at gmail dot com
Status: Assigned
Bug Type: PDO related
Operating System: Linux
PHP Version: 5.2.5
Assigned To: johannes
New Comment:
I renamed it to what MySQL calls it. Please just drop the defines then,
I copied them from mysql_com.h -- sorry, I am a n00b in doing this.
Please also drop any client flags you do not feel useful.
Previous Comments:
[2008-10-23 13:25:24] [EMAIL PROTECTED]
Thanks for the patch, a few comments/questions:
- Why are you renaming the connect_opts variable? Any particular
reason?
- You shouldn't use the numeric values, as they might change, but the
values provided by the client library, this also ensures that only flags
supported by the library are being used.
- I think the SSL flag won't work without specific SSL certs & stuff,
but I have to check that myself
[2008-10-23 01:34:27] chx1975 at gmail dot com
An attempt to fix this can be found at
http://drupal4hu.com/php-44135.patch . I added a number of flags not
just the one I needed.
running
PDO::MYSQL_CLIENT_FOUND_ROWS));
$p->exec('TRUNCATE a');
$p->exec('INSERT INTO a VALUES (1)');
echo $p->exec('UPDATE a SET a = 1 WHERE a = 1');
$p = new PDO('mysql:host=localhost;dbname=test', 'root', '');
echo $p->exec('UPDATE a SET a = 1 WHERE a = 1');
?>
shows a 1 (one row found) and then a 0 (0 updated) so the patch seems
to work.
[2008-02-16 03:29:44] larry at garfieldtech dot com
I can duplicate this problem. The issue appears to be that by
default, MySQL will return the number of affected rows from a
previous UPDATE statement, not the number of matched rows. That
values will differ if the update statement would set a row to its
existing value. With ext/mysql and ext/mysqli, it can be set to
return matched rows instead. PDO does not appear to have a way to
allow that.
----------------
[2008-02-16 03:26:34] chx1975 at gmail dot com
Description:
mysql_real_connect supports client flags
http://dev.mysql.com/doc/refman/4.1/en/mysql-real-connect.html most
importantly CLIENT_FOUND_ROWS but PDO provides no way to pass it in.
--
Edit this bug report at http://bugs.php.net/?id=44135&edit=1
#43342 [Com]: Add PDO constant MYSQL_ATTR_CLIENT_FOUND_ROWS in order to influence rowCount()
ID: 43342 Comment by: chx1975 at gmail dot com Reported By: glideraerobatics at hotmail dot com Status: Open Bug Type: Feature/Change Request Operating System: all PHP Version: 5.2.5 New Comment: http://bugs.php.net/bug.php?id=44135 is the same bug -- but this needs more than a constant because the CLIENT_FOUND_ROWS can only be passed in as a connection flag. Previous Comments: [2007-11-20 10:42:55] glideraerobatics at hotmail dot com Description: PDO is very similar in design to Perl's DBI which does allow you to set driver specific attributes such as mysql_client_found_rows=1 as part of the DSN. Setting the attribute mysql_client_found_rows=1 is Perl's DBD::mysql will make the rows() method (equivalent of PDO's rowCount()) return the number of rows matched for the update and not just those that were actually updated. This is a very useful/efficient feature as it prevents the need for doing 'SELECT COUNT(*)' queries before doing the updates and it prevents the need for locking too (since 2 statements are no longer atomic). PDO has a setAttribute() method, but there is as yet no MYSQL_ATTR_CLIENT_FOUND_ROWS constant. My request is that this be built into the PDO mysql driver. The information rowCount() will need can be retrieved from mysql_info(). -- Edit this bug report at http://bugs.php.net/?id=43342&edit=1
Bug #53632 [Com]: PHP hangs on numeric value 2.2250738585072011e-308
Edit report at http://bugs.php.net/bug.php?id=53632&edit=1 ID: 53632 Comment by: chx1975 at gmail dot com Reported by:exploringbinary at gmail dot com Summary:PHP hangs on numeric value 2.2250738585072011e-308 Status: Assigned Type: Bug Package:Math related PHP Version:5.3.4 Assigned To:dmitry Block user comment: N Private report: N New Comment: Excellent analysis at http://news.ycombinator.com/item?id=2066084 Previous Comments: [2011-01-04 10:57:51] stuart dot caie at gmail dot com Appears to hang when compiled for 32bit Intel code, but not 64bit code. Hangs in zend_strtod() according to gdb. [2011-01-04 10:17:02] paj...@php.net Happens here too 64bit CPU 32bit builds (win or linux) [2011-01-04 09:54:26] ras...@php.net How about -O2 -ffloat-store ? [2011-01-04 09:37:07] scott...@php.net looking like a gcc optimizer bug, -O0 is fine where -O2 hangs [2011-01-04 09:02:31] scott...@php.net This only seems to affect 32-bit systems. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=53632 -- Edit this bug report at http://bugs.php.net/bug.php?id=53632&edit=1
[PHP-BUG] Bug #54980 [NEW]: array_multisort uses second array to sort
From: Operating system: Irrelevant PHP version: Irrelevant Package: Arrays related Bug Type: Bug Bug description:array_multisort uses second array to sort Description: I thought array_multisort sorts the first array and orders the consequent arrays accordingly. Changing $sort['C'] to 3 indeed makes the error message go away so we think the error is only triggered if the sort does not happen in the first array. This is related to http://bugs.php.net/bug.php?id=54259 but I have simplified Brad's script as much as I can -- and he reported as a feature request. I think this is a bug. At least a documentation bug. Test script: --- $sort['A'] = 2; $sort['B'] = 1; $sort['C'] = 1; $menu['A'] = 0; $menu['B'] = (object) array(0); $menu['C'] = 0; array_multisort($sort, SORT_NUMERIC, $menu); Expected result: No error message shown Actual result: -- PHP Notice: Object of class stdClass could not be converted to int in /tmp/chx_array_multisort.txt on line 11 -- Edit bug report at http://bugs.php.net/bug.php?id=54980&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54980&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54980&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54980&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54980&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54980&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54980&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54980&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54980&r=needscript Try newer version: http://bugs.php.net/fix.php?id=54980&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54980&r=support Expected behavior: http://bugs.php.net/fix.php?id=54980&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54980&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54980&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54980&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54980&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54980&r=dst IIS Stability: http://bugs.php.net/fix.php?id=54980&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54980&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54980&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54980&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54980&r=mysqlcfg
Bug #60198 [Com]: Array to string notice from array functions
Edit report at https://bugs.php.net/bug.php?id=60198&edit=1 ID: 60198 Comment by: chx1975 at gmail dot com Reported by:simon at simon dot geek dot nz Summary:Array to string notice from array functions Status: Open Type: Bug Package:*General Issues PHP Version:5.4SVN-2011-11-02 (SVN) Block user comment: N Private report: N New Comment: This affects the Drupal project. All our tests are failing because of this bug. We see it with array_intersect_assoc(). Previous Comments: [2011-11-02 08:33:27] simon at simon dot geek dot nz Description: Some of the array_* functions that compare elements in multiple arrays do so by (string)$elem1 === (string)$elem2. If $elem1 or $elem2 is an array, then the array to string notice is thrown. Two examples of functions that can throw this are array_intersect() and array_diff(). If these functions are not expected to take arrays with other arrays as values, this should be mentioned on the documentation pages. Test script: --- b [1] => Array ( [0] => a ) ) Actual result: -- PHP Notice: Array to string conversion in /Users/simon/test.php on line 4 PHP Notice: Array to string conversion in /Users/simon/test.php on line 4 PHP Notice: Array to string conversion in /Users/simon/test.php on line 5 PHP Notice: Array to string conversion in /Users/simon/test.php on line 5 PHP Notice: Array to string conversion in /Users/simon/test.php on line 5 Notice: Array to string conversion in /Users/simon/test.php on line 4 Notice: Array to string conversion in /Users/simon/test.php on line 4 Array ( ) Notice: Array to string conversion in /Users/simon/test.php on line 5 Notice: Array to string conversion in /Users/simon/test.php on line 5 Notice: Array to string conversion in /Users/simon/test.php on line 5 Array ( [0] => b [1] => Array ( [0] => a ) ) -- Edit this bug report at https://bugs.php.net/bug.php?id=60198&edit=1
Bug #60198 [Com]: Array to string notice from array functions
Edit report at https://bugs.php.net/bug.php?id=60198&edit=1 ID: 60198 Comment by: chx1975 at gmail dot com Reported by:simon at simon dot geek dot nz Summary:Array to string notice from array functions Status: Bogus Type: Bug Package:*General Issues PHP Version:5.4SVN-2011-11-02 (SVN) Block user comment: N Private report: N New Comment: This should be changed to a documentation bug because up until now if you had outside knowledge that those arrays are the same (for eg they are empty) then this simply worked. If you decided to break it, then it needs to be documented as a change because from a user perspective it is one. Previous Comments: [2011-11-11 00:51:23] ras...@php.net The problem here is that these functions aren't recursive. They just go one level deep and assume arrays of scalars. This means that the notice is a good idea because the result when you pass it nested arrays is likely not the one you wanted. For example. If we change your code example slightly: $left = [ 1, 2, [3] ]; $right = [2, 'Array']; What should the intersection of these two be? Surely just the '2' since there is no nested array with a 3 in $right and there is no string 'Array' in $left. But the actual output is: [ 2, [3] ] Oops! That's not what we expected and that is why this result gives you a notice telling you that the result is likely flawed because of an array to string conversion. Now, it might be nice if array_intersect was smarter and could handle nested arrays, but that would be a different feature enhancement bug. It also looks like this is well-documented. The array_intersect() doc page has this highlighted note: Note: Two elements are considered equal if and only if (string) $elem1 === (string) $elem2. In words: when the string representation is the same. ---------------- [2011-11-11 00:05:29] chx1975 at gmail dot com This affects the Drupal project. All our tests are failing because of this bug. We see it with array_intersect_assoc(). [2011-11-02 08:33:27] simon at simon dot geek dot nz Description: Some of the array_* functions that compare elements in multiple arrays do so by (string)$elem1 === (string)$elem2. If $elem1 or $elem2 is an array, then the array to string notice is thrown. Two examples of functions that can throw this are array_intersect() and array_diff(). If these functions are not expected to take arrays with other arrays as values, this should be mentioned on the documentation pages. Test script: --- b [1] => Array ( [0] => a ) ) Actual result: -- PHP Notice: Array to string conversion in /Users/simon/test.php on line 4 PHP Notice: Array to string conversion in /Users/simon/test.php on line 4 PHP Notice: Array to string conversion in /Users/simon/test.php on line 5 PHP Notice: Array to string conversion in /Users/simon/test.php on line 5 PHP Notice: Array to string conversion in /Users/simon/test.php on line 5 Notice: Array to string conversion in /Users/simon/test.php on line 4 Notice: Array to string conversion in /Users/simon/test.php on line 4 Array ( ) Notice: Array to string conversion in /Users/simon/test.php on line 5 Notice: Array to string conversion in /Users/simon/test.php on line 5 Notice: Array to string conversion in /Users/simon/test.php on line 5 Array ( [0] => b [1] => Array ( [0] => a ) ) -- Edit this bug report at https://bugs.php.net/bug.php?id=60198&edit=1
