Bug #53132 [Opn->Csd]: PDO converts (int)0 to NULL
Edit report at https://bugs.php.net/bug.php?id=53132&edit=1
ID: 53132
Updated by: dharman@php.net
Reported by: novitools dot novi at web dot de
Summary: PDO converts (int)0 to NULL
-Status: Open
+Status: Closed
Type: Bug
Package: PDO MySQL
Operating System: Linux
PHP Version: 5.3.1
-Assigned To:
+Assigned To: nikic
Block user comment: N
Private report: N
New Comment:
The fix for this bug has been committed.
If you are still experiencing this bug, try to check out latest source from https://github.com/php/php-src and re-test.
Thank you for the report, and for helping us make PHP better.
Fixed by Nikita in PHP 8.1 back in December. See https://github.com/php/php-src/commit/caa710037e663fd78f67533b29611183090068b2
Previous Comments:
------------------------------------------------------------------------
[2020-08-28 15:20:08] cmb@php.net
> At this point some magic in the PDO core converts the desired
> value of NULL.
Well, if NULL was desired, why has PDO::PARAM_INT been given instead
of PDO::PARAM_NULL? Yes, rhethoric question.
> Purely out of interest, why does the test script emulates
> prepared statements?
Because that is default for PDO MySQL.
------------------------------------------------------------------------
[2011-01-04 18:29:00] novitools dot novi at web dot de
Sorry I forgot to set $Pdo->setAttribute(PDO::ATTR_DEFAULT_FETCH_MODE, PDO::FETCH_BOUND); in the
test case. In my projects the attribute is set, so I don't need to call fetch(PDO::FETCH_BOUND)
instead of fetch().
Purely out of interest, why does the test script emulates prepared statements?
I thought it really uses prepared statements like mysqli?
------------------------------------------------------------------------
[2011-01-04 16:22:25] uw@php.net
I don't think this is tied to MySQL, thus unassigning mysql.
The test script is using prepared statement emulation. It does first a bound fetch and then it does
another associative/indexed fetch. That's because the test script does not read
fetch(PDO::FETCH_BOUND), see also PDO documebntation on PDOStatement::fetch(). The result of the
associative/indexed fetch is ignored, however, for the sake of the NULL/0 discussion that's
irrelevant. It is only an aside note API usage.
Because the prepared statement emulation is not turned off explicitly PDO will emulate the query
using non-prepared statements. MySQL will hint the column type string to PDO for non-prepared
statements and, in case of the SQL value NULL, the PDO MySQL driver will pass a char* with the C
value of NULL to the PDO core. IMHO the driver job ends at this point. The driver, in this case
MySQL, has passed NULL to the PDO core.
At this point some magic in the PDO core converts the desired value of NULL. The magic is user
requested and part of bindColumn(). After fetching the char* NULL value from the MySQL driver and
converting it to a zval containing NULL the PDO core follows the instructions of the user and
converts NULL into a string (pdo_stmt.c, line 640ff, switch (new_type) ...).
This is basically what the PDO core does because of the conversion requested in bindColumn():
var_dump((int)NULL);
-> int(0)
I think the PDO core should preserve NULL values for all user-requested conversions. The PDO core
should handle NULL in that switch. A PDO driver that has returned a NULL value should not have to
worry about any conversion logic happening in the core.
Because I believe this is a PDO core bug and the PDO design should be altered, I have unassigned the
bug from group mysql.
------------------------------------------------------------------------
[2010-11-22 10:41:32] uw@php.net
What about PHP 5.3.4-RC. Is it specific to mysqlnd or libmysql?
------------------------------------------------------------------------
[2010-11-08 20:45:05] novitools dot novi at web dot de
Same Problem with 5.3.1.
------------------------------------------------------------------------
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=53132
--
Edit this bug report at https://bugs.php.net/bug.php?id=53132&edit=1
Thread (9 messages)