Edit report at https://bugs.php.net/bug.php?id=63419&edit=1
ID: 63419
Updated by: php-bugs@lists.php.net
Reported by: daniel dot kinzler at wikimedia dot de
Summary: PDO::quote for SQLite truncates strings on \0
-Status: Feedback
+Status: No Feedback
Type: Bug
Package: PDO related
Operating System: Ubuntu 11.10
PHP Version: 5.3.18
Private report: N
New Comment:
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Re-Opened". Thank you.
Previous Comments:
------------------------------------------------------------------------
[2013-10-24 07:30:03] yohgaki@php.net
FYI
quoting is done by PHP, not SQLite, since there is no such API in SQLite3.
------------------------------------------------------------------------
[2013-10-24 07:28:53] yohgaki@php.net
I'm not sure if this change is usable or not.
SQLite3 does not have quote feature. It only has prepared query type API. Even if I change quote
method, it may not work.
Are you sure quote works with null byte escapes? If I were sqlite3 developer, I just don't care
escaped chars, etc, in a SQL string since there should not be such chars in SQL query definition
strings.
If you find out it works, this behavior may be fixed.
------------------------------------------------------------------------
[2012-11-02 11:30:47] daniel dot kinzler at wikimedia dot de
I'd like to add some information about my use case for this. I was storing serialized PHP
objects in the database. Serialized PHP objects seem to use NUL (\0) to mark protected and private
fields. Trying to store such a string into SQLite would truncate it, effectively rendering the
serialized data unusable.
Now, why the hell does PHP use \0 in the serialized representation of objects?! Serializations
should be robust and designed with interoperability in mind! Oh well, I guess that's a rant for
another time.
------------------------------------------------------------------------
[2012-11-02 11:16:39] daniel dot kinzler at wikimedia dot de
Sorry, here's the correct version of the test script:
<?php
// This contains ASCII 0x00 aka \0
$data = "x\0y";
$pdo = new PDO( "sqlite:test", '', '', array( PDO::ATTR_PERSISTENT
=> false ) );
$result = $pdo->quote( $data );
print "Raw: " . $result . "\n";
print "Hex: " . bin2hex( $result ) . "\n";
------------------------------------------------------------------------
[2012-11-02 11:06:17] daniel dot kinzler at wikimedia dot de
Description:
------------
PDO::quote for SQLite is not binary safe, it silently truncates strings on \0. Either, \0 should be
supported, or the method should trigger a warning if \0 is found and return false.
Note that the same problem exists with SQLite3::escapeString, see Bug 62361. In that report, someone
pointed to SQLite's mprintf as the culprit <http://www.sqlite.org/c3ref/mprintf.html>.
From mprintf's documentation:
"The %q option works like %s in that it substitutes a nul-terminated string from the argument
list."
It operates on null-terminated strings, so null must not be present in strings. PDO needs to work
around this fact.
Test script:
---------------
<?php
// This contains ASCII 0x00 aka \0
$data = "x\0y";
$pdo = new PDO( "sqlite:test", '', '', array( PDO::ATTR_PERSISTENT
=> false ) );
print "PDO/SQLite: " . bin2hex( $pdo->quote( $data ) ) . "\n";
Expected result:
----------------
Raw: 'xy'
Hex: 2778007827
Note that the 'xy' above is intended to contain an invisible null character.
Alternatively, the hex representation could be used:
Raw: x'2778007827'.
That would probably be the safest option, and should Just Work with existing code.
Actual result:
--------------
Raw: 'x'
Hex: 277827
------------------------------------------------------------------------
--
Edit this bug report at https://bugs.php.net/bug.php?id=63419&edit=1