Bug #53132 [Opn]: PDO converts (int)0 to NULL

From: Date: Fri, 28 Aug 2020 15:20:08 +0000
Subject: Bug #53132 [Opn]: PDO converts (int)0 to NULL
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-228786@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=53132&edit=1 ID: 53132 Updated by: cmb@php.net Reported by: novitools dot novi at web dot de Summary: PDO converts (int)0 to NULL Status: Open Type: Bug Package: PDO MySQL Operating System: Linux PHP Version: 5.3.1 Block user comment: N Private report: N New Comment: > 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. Previous Comments: ------------------------------------------------------------------------ [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. ------------------------------------------------------------------------ [2010-11-08 18:16:15] uw@php.net 5.2 only gets critical security updates. "This release marks the end of the active support for PHP 5.2. Following this release the PHP 5.2 series will receive no further active bug maintenance. Security fixes for PHP 5.2 might be published on a case by cases basis. All users of PHP 5.2 are encouraged to upgrade to PHP 5.3.", http://www.php.net/archive/2010.php#id2010-07-22-1 Please try with 5.3 ------------------------------------------------------------------------ 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

« previous php.bugs (#228786) next »