Fix bug #54379 PDO_OCI: UTF-8 output gets truncated

[kissifrot]

I can test a Windows build ogf PHP with that fix if needed.

[kissifrot]

Added test.

[cjbj]

I scanned the change quickly. The code looks delicate. It defines the new size in terms of a utext (a short) which is intended for utf-16. If this sizing code is the root cause of the crash, I would have expected the patch to use oratext or text with some character set multiplication factor.

The test uses the wrong number of args to putenv() so it will fail. It hardcodes the connection string and char set. It should also have a skipif if the DB char set is not UTF8.

[kissifrot]

Which patch?

[lstrojny]

Can you squash the commit?

[gureedo]

It is not quite right solution.
Oracle docs defines three versions of utf8 encoding.

• AL32UTF8 and UTFE character can occupy up to 4 bytes.
• UTF8 character can occupy up to 6 bytes.
  Details here: http://docs.oracle.com/cd/B19306_01/server.102/b14225/ch6unicode.htm#i1006998
  We can obtain maximum character size in bytes by calling OCINlsNumericInfoGet() and get current max character width.
  Details here: http://docs.oracle.com/cd/B10501_01/server.920/a96529/ch8.htm#14288

There is also another one caveat: NCHAR, NVARCHAR2, NCLOB types. Before transferring data to client Oracle converts data from such columns to NLS_NCHAR character set (if it is defined). Look here for details: http://docs.oracle.com/cd/A84870_01/doc/server.816/a76966/ch2.htm#94684
So, if NLS_NCHAR defined with different character set than connection charset or NLS_LANG, we can get invalid max character width for such columns.

I see here two ways.

1. Always multiply data_size by 4, and not support old UTF8 (Unicode 3.0) character set.
2. Detect character set and multiply by obtained max width.

But i don't know what to do with NLS_NCHAR.

[gitgitcode]

use oci function cast() like this :
select cast( tbl.description AS
varchar2(300) )as desc FROM database.table tbl;
it work 🎱

[cofirazak]

Can anyone clarify the status of this bug?
I've recompiled yestarday php with this fix to col->maxlen in oci_statement.c given by kissifrot, and it solved this bug.
So now i wonder why this bug is so old and still not merged in the master branch?
Can anyone clarify this please?

[php-pulls]

Comment on behalf of krakjoe at php.net:

Since this PR has merge conflicts, seems to have been abandoned by author, and seems like a questionable solution, I'm closing this PR.

If the author is watching and feels I am wrong, please open a clean PR, and start a discussion on internals.

[kissifrot]

Well the original PR was more a quick hack than a real fix.
There is another PR and a different fix, #542 , about this