|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #5444 Long VARCHARs create invalid strings
Submitted: 2000-07-07 21:23 UTC Modified: 2006-07-17 09:05 UTC
From: schmidt at bcc dot de Assigned:
Status: Not a bug Package: OCI8 related
PHP Version: 4.0.1pl2 OS: linux 2.2 / glibc 2.1.3
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Bug Type:
From: schmidt at bcc dot de
New email:
PHP Version: OS:


 [2000-07-07 21:23 UTC] schmidt at bcc dot de
Any select command on VARCHARS (256+) does not return a "regular" string, but (following a tcpdump) contains 0<CHAR>0<CHAR>0<CHAR>...
This causes a non-display with Netscape (not even visible in page source) 4.7x on Linux & Win (at least). Lynx and MSIE (at least) do work.
I consider this a bug, as with PHP 3 the output was valid (and visible with Netscape).

I'm using Oracle Linux - my PHP configuration command was
--without-pgsql --without-mysql --with-oci8 --with-zlib --sysconfdir=/etc --without-gd --with-apxs
The webserver is not the same as the db machine, if this matters.

The table is like 
create table tab (col1 varchar(256), col2 varchar(256), col3 varchar(256))
and the code used to print looks like

function _db_nextresult($result) {
        if (OCIFetchInto($result, $fetcharray, OCI_ASSOC)) {
                return $fetcharray;
        } else {
                return false;

for ($result_b = _db_nextresult ($result), $i=0; $result_b; $i++) {
        while (list ($key, $val) = each ($result_b) ) {
                echo "$key - $val<BR>";
        $result_b = _db_nextresult ($result);

Note that with 
printf ("%s - %s<BR>\n", $key, $val);
you wan't see a single thing, not even with lynx or MSIE, as IMHO the zero in the string terminates it before the first character is printed. It also becomes quite difficult to parse the string and replace the zeroes....

If you want to take a look at it, feel free to visit for a php test and for the problem...


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2000-07-07 22:53 UTC] schmidt at bcc dot de
It appears not to depend on the length of the varchars, but it works on a BSD box where I still have to find the configure params...
Maybe it's a NLS or UTF or something else character encoding specific. The data presented by Oracle already contains the zeroes (text is "admin", retlen=10). A side effect of this is, a 8 chars text in a varchar(10) can't be read and is truncated, a 18 chars text in a varchar(20) is cut after the first char, and it doesn't throw a warning...
OCIDebug: _oci_make_zval: CUSTID,retlen = 11,retlen4 = 0,storage_size4 = 11,indicator 0, retcode = 0
for "longtest", 
0a40  0a 43 55 53 54 49 44 20  2d 20 00 6c 00 6f 00 6e   .CUSTID. -..l.o.n 
0a50  00 67 00 74 00 3c 42 52  3e 4e 41 4d 45 20 2d 20   .g.t.<BR >NAME.-. 
is returned.
OCIDebug: _oci_make_zval: NAME,retlen = 1,retlen4 = 0,storage_size4 = 21,indicator 0, retcode = 0
OCIDebug: _oci_make_zval: PASSWORD,retlen = 2,retlen4 = 0,storage_size4 = 21,indicator 0, retcode = 0
 [2000-07-09 13:06 UTC] thies at cvs dot php dot net
please make sure that ORACLE_HOME, ORACLE_SID and NLS_LANG are setted in your environment *before* you start apache. do not use PutEnv() in your php-script or SetEnv in your httpd.conf or .htaccess.

PHP Copyright © 2001-2020 The PHP Group
All rights reserved.
Last updated: Wed Jan 29 11:01:24 2020 UTC