#38061 [NEW]: php_oci_lob_read counts bytes read incorrectly for CLOBs

From: dcowgill at communityconnect dot com Operating system: Linux PHP version: 5.1.4 PHP Bug Type: OCI8 related Bug description: php_oci_lob_read counts bytes read incorrectly for CLOBs Description: ------------ OCI-Lob->read returns empty string, even when OCI-Lob->size is non-zero and lob offset is 0; tested with oracle 10.1.0.3 and 10.2.0.1 Reproduce code: --------------- The example labeled "Example 3. Inserting data into a CLOB column" in the OCI8 section of the PHP manual (http://us2.php.net/manual/en/ref.oci8.php) demonstrates the problem perfectly. Expected result: ---------------- As described in the example in the php manual. Actual result: -------------- No clob data is returned; same outcome when fetching with the OCI_RETURN_LOBS bit set, or when using a bind variable. The bug appears to be in php_oci_lob_read (ext/oci8/oci8_lob.c) -- specifically, in the #ifdef HAVE_OCI_LOB_READ2 branch. OCILobRead2 always sets byte_amtp to 0 when char_amtp is provided and the data type is clob; but on line 251, data_len is incremented by byte_amtp. The OCI docs are, not surprisingly, characteristically vague about these parameters, and the description at http://download-east.oracle.com/docs/cd/B19306_01/appdev.102/b14250/oci16msc002.htm#sthref3022 is not much help: "byte_amtp (IN/OUT) IN - The number of bytes to read from the database. Used for BLOB and BFILE always. For CLOB and NCLOB, it is used only when char_amtp is zero. OUT - The number of bytes read into the user buffer." That sounds like byte_amtp should always have a value on output, even if char_amtp was non-zero and the data type is CLOB or NCLOB, but my oracle client certainly doesn't do that. It always sets *byte_amtp to zero unless char_amtp is null. Tested with out-of-the-box installs of oracle 10.1.0.3 and 10.2.0.1 -- Edit bug report at http://bugs.php.net/?id=38061&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=38061&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=38061&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=38061&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=38061&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=38061&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=38061&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=38061&r=needscript Try newer version: http://bugs.php.net/fix.php?id=38061&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=38061&r=support Expected behavior: http://bugs.php.net/fix.php?id=38061&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=38061&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=38061&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=38061&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38061&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=38061&r=dst IIS Stability: http://bugs.php.net/fix.php?id=38061&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=38061&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=38061&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=38061&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=38061&r=mysqlcfg