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