ID: 35103 User updated by: php at pjberkel dot com Reported By: php at pjberkel dot com -Status: Closed +Status: Open Bug Type: MySQLi related Operating System: * -PHP Version: 5CVS-2005-11-04 (cvs) +PHP Version: 5.1CVS-2005-12-02 (cvs) Assigned To: andrey New Comment:
I tested my original reproduce code using the lastest stable snapshot available (php5.1-200512020130), but there appears to be another bug (or feature) introduced because no output is being generated at all. It appears as though $stmt->fetch() is returning NULL despite the fact that it correcly bound the result set. I notice in the manual page that mysqli_stmt_fetch() returns NULL when "No more rows/data exists or data truncation occurred". Can anybody confirm this is a bug or feature? FYI I'm testing this with MySQL 5.0.16 on RHEL 4. Previous Comments: ------------------------------------------------------------------------ [2005-11-30 17:26:36] [EMAIL PROTECTED] 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. ------------------------------------------------------------------------ [2005-11-21 21:52:34] [EMAIL PROTECTED] I have a fix for this problem as well as speedup of the current code that handles unsigned ints on 32bit but I will push it after 5.1.0 is released because it's a bit too late in the release cycle. ------------------------------------------------------------------------ [2005-11-15 18:37:22] [EMAIL PROTECTED] I am taking care of this problem. Thanks! ------------------------------------------------------------------------ [2005-11-10 08:54:25] [EMAIL PROTECTED] Andrey, really REALLY big ints don't work yet! :) ------------------------------------------------------------------------ [2005-11-10 04:36:13] php at pjberkel dot com I compiled the latest CVS snapshot from the 5.1 branch (php5-200511100130) and can confirm that the problem has been fixed for 32bit unsigned INT values. However, I also did some further testing using the unsigned BIGINT data type (which contain 64bit integer values) and discovered the same problem exists for unsigned values larger than the maximum signed 64bit value: (9223372036854775807 < int <= 18446744073709551615) (BTW I'm using http://dev.mysql.com/doc/refman/5.0/en/numeric-types.html as a reference page for MySQL numerical types.) Changing the following two lines in the original reproduce code fragment: $mysqli->query("CREATE TABLE temp (id BIGINT UNSIGNED NOT NULL)"); $mysqli->query("INSERT INTO temp (id) VALUES (9223372036854775807),(9223372036854775808),(18446744073709551614),(18446744073709551615)"); Expected result: ---------------- string(19) "9223372036854775807" string(19) "9223372036854775808" string(20) "18446744073709551614" string(20) "18446744073709551615" Actual result: -------------- string(19) "9223372036854775807" string(20) "-9223372036854775808" int(-2) int(-1) I don't want to push the envelope too much on this as I guess it would be extremely rare for anyone to encounter this bug, but if there is a quick, easy solution then it's probably a good idea to fix the unsigned BIGINT problem too. Any plans to backport this to the 5.0.x branch? Thanks ------------------------------------------------------------------------ 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/35103 -- Edit this bug report at http://bugs.php.net/?id=35103&edit=1
